lkml.org 
[lkml]   [1998]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PROPOSAL: /proc/dev
    Theodore Y. Ts'o writes:
    > Date: Fri, 9 Jan 1998 11:40:03 +1100
    > From: Richard Gooch <rgooch@atnf.CSIRO.AU>
    >
    > If I understand what you mean, there would be problems. Device drivers
    > which use devfs (in a devfs-enabled kernel) would *only* be accessible
    > through a mounted devfs. Other device drivers which are not yet
    > converted to be devfs-capable (i.e. with #ifdef CONFIG_DEVFS wrappers)
    > would *only* be accessible through the old disc-based c&b nodes.
    >
    > The is an important difference between the way disc-based c&b nodes
    > and devfs make the connection between an entry in /dev and the actual
    > device driver.
    >
    > Note that the devfs doesn't use the major&minor system.
    >
    > I thought you said devfs would be compatible with people who need to
    > create a subset of /dev with character and block devices in (say)
    > /u1/ftp/dev for the purpose of creating chroot'ed jail....
    >
    > Now you're saying that devfs will *not* be compatible with somone who
    > needs to use chroot --- say, in anonymous FTP servers. Worse yet, as
    > device drivers are converted over to use devfs, it will be impossible to
    > use such devices in an chrooted system?
    >
    > Say it isn't so....

    Er, I don't think there is a problem. I've appended the relevant
    sections from the latest README, which I hope clarifies it.

    Regards,

    Richard....
    ===============================================================================
    Chroot() gaols
    --------------
    The semantics of inode creation are different when the devfs is
    mounted with the "explicit" option. Now, when a device entry is
    registered, it will not appear until you use mknod() to create the
    device. It doesn't matter if you mknod() before or after the device is
    registered with dev_register(). The purpose of this behaviour is to
    support chroot(2) gaols, where you want to mount a minimal devfs
    inside the gaol. Only the devices you specifically want to be
    available (through your mknod() setup) will be accessible.

    Installation during the transition phase
    ========================================

    Currently, not all device drivers in the kernel have been modified to
    use devfs. To allow booting of kernels with and without devfs support,
    you will want to copy the contents of /dev to /olddev. Then, remove
    entries in /dev which are now available in devfs and make them
    symbolic links to the entries in /olddev.
    Finally, edit your /etc/fstab or boot scripts so that devfs is mounted
    over /olddev on bootup. If devfs is supported, accessing devices
    supported by devfs will follow the symlinks to devfs. If devfs is not
    supported, accessing those same devices will follow the symlinks to
    /olddev which contains only old-style device nodes.
    Devices not supported by devfs will be found directly on /dev.
    Simple! You can also follow this principle for chroot gaols.

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:4.121 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site