Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Jan 2001 20:40:01 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        Peter Wemm <peter@netplex.com.au>, freebsd-arch@FreeBSD.ORG
Subject:   Re: Cloned open support 
Message-ID:  <23397.980797201@critter>
In-Reply-To: Your message of "Mon, 29 Jan 2001 18:38:24 GMT." <200101291838.f0TIcO203434@hak.lan.Awfulhak.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200101291838.f0TIcO203434@hak.lan.Awfulhak.org>, Brian Somers writes:
>> Brian Somers wrote:
>> > Hi,
>> > 
>> > I'm considering having a crack at adding support for cloned opens.
>> > Before I start, I guess I've got two questions:
>> > 
>> > 1.  Is anybody else doing this.
>> > 
>> > 2.  Given that I'll need to change the d_open prototype (and
>> >     thus cdevsw), I'm going to affect every device driver in the
>> >     tree - although only changing the first arg to a (dev_t)
>> >     pointer, making things pretty easy to change and not too
>> >     unexpected for anyone that's written sysv drivers.
>> 
>> Not necessary.  dev_t *is* a pointer.  Add a flag to the device flags to
>
>Ach, I was thinking userland-dev_t aka udev_t :-/  Yes, the 
>prototypes don't need to change :-D

It would have to change, it would have to be pointer to pointer to
do it the way you propose.

>I *guess* it's cleaner to create the new vnode so that the namei 
>caching side of things can do it's job on the clone device.

That was my conclusion as well :-)

In addition it allows cloning in some cases which would otherwise
not be possible.  One I know various people have been seen drooling
over is media determined disk names.  The driver and label/slice
code could read various identifiers off the disk and allow people
to do things like:

	mount /dev/disk/serial/234723842 /mnt


--
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?23397.980797201>