[Devel] Re: [RFC][PATCH 0/8][v2]: Enable multiple mounts of devpts

[sukadev at us.ibm.com]

H. Peter Anvin [hpa at zytor.com] wrote:
> sukadev at us.ibm.com wrote:
>> TODO:
>> 	- Remove even initial kernel mount of devpts ? (If we do, how
>> 	  do we preserve single-mount semantics) ?
>
> Doesn't make sense unless we decide to drop single-mount semantics in the 
> (far) future. As long as we have an instance that services unconnected ptmx 
> instances, it makes sense to have that instance available to the kernel at 
> all times.
>
> I don't like the name "newmnt" for the option; it is not just another 
> mount, but a whole new instance of the pty space.

I agree.  Its mostly a place-holder for now. How about newns or newptsns ?

>
> I observe you didn't incorporate my feedback with regards to get_node().   

Yes, I have not addressed it yet. Will look into it in the next pass,
but will add to the todo list now.

> In this scheme, any and all uses of get_node() are bogus; as such, you're 
> missing the huge opportunity for cleanup that comes along with this whole 
> thing.
>
> This means breaking compatibility in one very minor way, which is if people 
> copy device nodes out of /dev/pts, but I am feeling pretty sure that that 
> is much better than carrying the ugliness that goes along with the current 
> code.  Furthermore, if there are anyone who do something that silly, they 
> need to fix it anyway.
>
> The *entire* implementation of devpts_get_tty(), for example, should look 
> like:
>
> struct tty_struct *devpts_get_tty(struct inode *inode)
> {
> 	struct super_block *sb = inode->i_sb;
> 	
> 	if (sb->s_magic == DEVPTS_SUPER_MAGIC)
> 		return (struct tty_struct *)inode->i_private;
> 	else
> 		return NULL;	/* Higher layer should return -ENXIO */
> }
>
> I really appreciate your tackling this implementation.
>
> 	-hpa
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers