Date: Tue, 18 Jul 2000 15:12:18 -0700 From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> 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: <3974D642.59E2B600@elischer.org> References: <4772.963868830@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
>
> In message <397357D7.167EB0E7@elischer.org>, Julian Elischer writes:
> >Poul-Henning has some well meaning ideas but I disagree
> >with him on several topics..
> >
> >1/ jail/chroot cannot be ignored..
> >see my email on cdevs using a "60 byte" major number
> >for a solution to this..
>
> I'm not saying it can be ignored. I'm saying that it is not
> worth complicating the issue with big time.
>
> 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...
I didn't say it was a magic bullet. I think it's a useful addition.
>
> >2/ The root mount problem can be easily solved if you allow
> >the kernel to open devices by name from the devfs namespace
> >without first mounting the device in user space.
> >I did this on the code He and sos deleted and it worked just fine.
>
> No, your code still built a vnode with no backing filesystem (it
> had no v_mount for instance) and that still forced a lot of special
> case code in generic vfs functions).
Actually I did have a v_mount that the root pointed to.
>
> >> For a moment, disregard jails and rootmounts and let us just look at
> >> cloning.
> >
> >they cannot be ignored as thay represent a significant usage model.
> >many programs expect a working /dev/tty for example.
>
> But /dev/tty can just be mknod(8)'d in the jail, and it will just
> work as it should.
That implies preallocating a major number.
That's one of the things I'm trying to get away from.
ASAP. (Also one of the thing kinus is trying to get away from with
their devfs.)
look up by NAME not by NUMBER....
>
> >> Next, let us look at the rootfs:
> >>
> >> Today when we boot a FreeBSD system, various magic code finds and
> >> mounts a root filesystem from which we execute /sbin/init (and the
> >> rest becomes history).
> >>
> >> A part of this ha^h^hmagic, is to take a device name, and come up
> >> with a vnode from which we can mount it, despite the fact that we
> >> have no filesystems mounted which can instantiate that vnode.
> >> Rather hackish, all in all.
> >
> >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.
Presently it has the "internal" mountpoint for the devfs
backing layer before the root is mounted. this is a valid
mountpoint from the point of view of all the code that looks at it.
>
> >> Other magic code will do similar gyrations to mount a NFS root
> >> filesystem.
> >
> >Since you don't need a device to mount an NFS filesystem this
> >is not directly relevent.
>
> see later. (always read the entire message before replying :-)
I did
>
> >> Finally, jails:
> >>
> >> The only reason there could ever be to mount a devfs in a jail
> >> partition is to get access to the cloning facility, mainly for
> >> ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned
> >> mknod(8) will do just fine. Remember: the main reason for devfs
> >> is to cater for dynamic devices, the main thing we don't want to
> >> see pop up in jails is dynamic devices.
> >
> >If we us a "SYMLINK-LIKE" major number replacement,
> >that links an on-disk device inode to the current devfs
> >canonical namespace, then no extra devfs's need to be mounted,
> >and the cloning facilities in devfs will be available
> >to any inode that links to a cloning device.
>
> 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.
You can still get clashes on strings I know, but it's a different
order of magnitude..
>
> --
> 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.
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
;_.---._/ presently in: Budapest
v
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?3974D642.59E2B600>