Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Jan 2001 15:46:47 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Peter Wemm <peter@netplex.com.au>, Brian Somers <brian@Awfulhak.org>, freebsd-arch@FreeBSD.ORG
Subject:   Re: Cloned open support 
Message-ID:  <21634.980779607@critter>
In-Reply-To: Your message of "Mon, 29 Jan 2001 15:39:27 %2B0100." <21576.980779167@critter> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <21576.980779167@critter>, Poul-Henning Kamp writes:

>>Well, how do we support Unix98 /dev/ptmx then?  This is not an academic
>>question, Linux apps are starting to do it this way and if we want to run
>>anything that uses ptys....
>>
>>          int fdm fds;
>>          char *slavename;
>>          extern char *ptsname();
>>
>>          fdm = open("/dev/ptmx", O_RDWR);   /* open master */
>>          grantpt(fdm);                      /* change permission ofslave */
>>          unlockpt(fdm);                     /* unlock slave */
>>          slavename = ptsname(fdm);          /* get name of slave */
>>          fds = open(slavename, O_RDWR);     /* open slave */
>>
>>Opening the master allocates you a private unit of the device with its own
>>minor number.
>
>We will support it just like that.  pts_clone() will recognize the "ptmx"
>name.  Create a new dev_t and return it.  Getting the name can be done
>with fstat(2) and devname(3).  A transformation to slave name is needed
>but that will always be needed. and it will DTRT.
>
>In fact, I think you can implement this in less than 20 lines of code total.

There is one more thing you have to do: in fs/devfs/devfs_vnops.c you need
to modify the loop right before the "notfound:" label to recognize the
new entry by the dev_t instead of the name, since the clone function
creates a dev_t for another name.  That will probably be faster in the
normal case as well...

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21634.980779607>