Date: Thu, 24 Sep 1998 00:47:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rotel@indigo.ie Cc: sos@FreeBSD.ORG, abial@nask.pl, peter@netplex.com.au, jkh@time.cdrom.com, current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <199809240047.RAA15840@usr07.primenet.com> In-Reply-To: <199809222341.AAA01550@indigo.ie> from "Niall Smart" at Sep 23, 98 00:41:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Soren, you said you used DEVFS without SLICE on regular basis. Tell me
> > > then, please, what for, because I can't see what (significant) added
> > > functionality over standard /dev/* it offered...
> >
> > It doesn't give me anything but an emptier looking /dev with only those
> > devices in it that I actually have :)
>
> I tried DEVFS for the first time today and thats about what I see
> too. What exactly is its purpose -- to replace a shell script? Am
> I missing something or is this a solution looking for a problem?
1) To never have the possibility of the /dev directory having
out-of-date contents.
2) To allow NFS booting from systems that don't support the 32
bit minor device numbers required by FreeBSD.
3) To move the maintenance of the MAKEDEV into the same source
file as the device being maintained, such that coherency is
automatic.
4) To allow for dynamic creation of devices as a result of
hot insertion or hot swap.
5) To allow for daemon-select/poll of the /dev directory to
allow for scanning to actually *do* something when a
device "arrives" (like mount an FS on a Flash, bring a
network link up when a PCMCIA net card is inserted, etc.).
6) To reduce the number of kernel drivers that have to be
working to get FreeBSD minimally functional on a new
piece of hardware.
7) To allow the creation of sub-instances of /dev in chroot
environments, but to omit "dangerous" or "undesirable"
devices.
8) To prevent the use of ad-hoc created devices (via mknod)
as gateways for security exploits.
9) To get rid of "specfs" and the promiscuous knowledge of
"specfs" in other areas of the kernel.
10) To aid in the murder of "struct fileops", such that vnodes
actually point to VFS devices.
11) To allow advisory locking to be applied to device files,
just like it applies to ordinary files.
12) Because it's cool.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809240047.RAA15840>