Date: Wed, 19 Jul 2000 09:58:17 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Warner Losh <imp@village.org>, Kelly Yancey <kbyanc@posi.net>, Dan Nelson <dnelson@emsphone.com>, Adrian Chadd <adrian@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) Message-ID: <2732.963993497@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 18 Jul 2000 15:12:18 PDT." <3974D642.59E2B600@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3974D642.59E2B600@elischer.org>, Julian Elischer writes:
>> Your "symlink device node" proposal still doesn't solve the
>> cloning problem, so it is only 1/2 a solution to what in
>> practice is a non-problem.
>
>It allows the cloning devices to be represented
>all over the filesystems rather than limitted to the devfs,
>thus it allows them to be in chroot/jails without zillions
>of devfs mounts...
No it doesn't. You "symlink" idea just replaces the major+minor
with a string, that's all.
Cloning can be done two ways, which I will illustrate with the pty
driver as example:
A) You open "/dev/pty", which clones and does some h0h0magic
with vnodes and fdesc.
You call ioctl(fd, WHATSMYREALNAME, buf, sizeof(buf))
and it tells you that you are really "/dev/pty102".
B) You try to open ("/dev/pty%d",N) for N [0...]
Once an open succeeds you have your fd and your name.
(this is what we do today)
In scenario A) in a jail, we may not have a /dev/pty102 entry
in /dev and we would have to try to create it. Creating device
nodes in jails is a NO-NO thing, and adding h0h0magic code to
allow this for ptys anyway is at best a gross hack.
*This* is the cloning problem in jails.
In scenario B) this is not a problem, but a configuration issue:
you have to create sufficient many ptys when you setup the jail.
Jails were never meant to be a 100% faithfull rendition of a FreeBSD
system, and in particular emphasis was put on it being a lightweight
implementation. If jails get in the way of something in the central
core of FreeBSD, jails have to give way.
Anyway, since we cannot make devfs mandatory right away anyway,
we will have to leave th cdevsw[] around for a while. (It could
be changed to use the "cloning-callback" and I may attempt to
make it do that before anything else is done since that solves some
issues with disks as well.) So I'm leaning heavily against
model B) right now, since it gives us total backwards compatibility.
>> >devfs as it is now has routines to do this..
>>
>> No it hasn't, the vnode still has to be magically handled because
>> it doesn't have a mountpoint.
>
>It Is magically handled. it would still have to be magically
>handled in any scheme you've mentionned so far.
No. Devfs can be mounted without calling namei. Once devfs is
mounted, the root mount can use a normal namei and the device
node will come out of a plain mount with no magic code.
>> Your "SYMLINK-LINK" proposal offers nothing that we don't already
>> have with major/minor identification, which for all intents
>> and purposes we will have to retain compatibility with for quite
>> some time anyway.
>
>We have pre-allocated major numbers. One of the MAIN aims
>of devfs was to make ALL devices dynamically loadable,
>which implies not limitting yourself to
>preallocated numbers.
I agree that this is a laudable goal, but right now it doesn't
help us, and consequently I would rather postpone it until we
are over the first hurdle, rather than put more spices in the
pot at this time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD coreteam member | 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?2732.963993497>