Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 18334.980748975@critter Poul-Henning Kamp writes: : 1. Say I want to use DEVFS, what should I change? : : Nothing. Just add DEVFS to your kernel config file. So it updates /dev all by itself? What if I want dev nodes elsewhere in the tree, say for a jail? mount -t devfs devfs /home/jail/dev would work, but all dynamic devices would appear there too. Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev To solve that problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It seems that "read my lips: no new devices" should be an option you can set from the very initial mount so that people can't also figure out how to get root, remove a /dev entry and replace it with one of their own. Come to think of it, there should also be a -o staticdev option to disallow *any* changes after the initial mount. That would make some of our more paranoid sysadmins happy. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Jordan Hubbard writes: Once we have an extensible facility for mount options, you will be able to say: mount -t devfs devfs /home/jail/dev ( cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ) mount -u -o nonewdev /home/jail/dev Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It seems that "read my lips: no new devices" should be an option you can set from the very initial mount so that people can't also figure out how to get root, remove a /dev entry and replace it with one of their own. Come to think of it, there should also be a -o staticdev option to disallow *any* changes after the initial mount. That would make some of our more paranoid sysadmins happy. That's called "mount -o ro" :-) I have not finalized the workings of the options, right now we have a 32-bit bitmap of mountoptions and they're all used up, and I don't have the time and bikeshedcarpenter hours to design a new mount option implementation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. And again, it hinges on an extensible set of mount options. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Warner Losh write s: In message [EMAIL PROTECTED] Jordan Hubbard writes: : Couldn't you also do "mount -t devfs -o nonewdev devfs /home/jail/dev" : and then cd /home/jail/dev ; rm $devices_i_dont_want_in_my_jails ? It : seems that "read my lips: no new devices" should be an option you can : set from the very initial mount so that people can't also figure out : how to get root, remove a /dev entry and replace it with one of their : own. Come to think of it, there should also be a -o staticdev option : to disallow *any* changes after the initial mount. That would make : some of our more paranoid sysadmins happy. My concern is that I usually know what devices I want (/dev/null, /dev/zero, /dev/tty). That makes it harder to delete all of them not on the list. I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. As bizzare as it sounds, I like Julian's hack for populating this stuff... ie: use a hard link to propagate nodes to the jailed /dev. eg: mount -t devfs -o empty /home/jail/dev ln /dev/null /home/jail/dev/null ln /dev/zero /home/jail/dev/zero ... mount -u -o ro /home/jail/dev It solves several problems, but is kinda odd as it involves a cross-filesystem hard link. This is another way oround the "oops, I didn't mean to rm /dev/null" - ie: mount -t devfs /mnt ln /mnt/null /dev umount /mnt The VOP_LINK() stuff has access to the source and destination, so it doesn't have to guess what do do on incomplete information (eg: fake major number). On the other hand... Suppose whiteouts were implemented... mount -t devfs -o empty /home/jail/dev cd /home/jail/dev rm -W null zero log mount -u -o ro /home/jail/dev ie: start with the initial state as "whiteouts on everything" and then selectively remove the whiteout for things you actually want... Then freeze it by flipping on the readonly bit. And again, it hinges on an extensible set of mount options. Yeah. Maybe pass in arbitary strins "empty" instead of trying to convert everything to a flag bit? I've been bothered about this for a while. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
I have seriously been thinking about some way to say something like mount -t devfs -o jailset /home/jail/dev but an elegant implementation evades me at this moment. As bizzare as it sounds, I like Julian's hack for populating this stuff... ie: use a hard link to propagate nodes to the jailed /dev. eg: mount -t devfs -o empty /home/jail/dev ln /dev/null /home/jail/dev/null ln /dev/zero /home/jail/dev/zero ... mount -u -o ro /home/jail/dev It solves several problems, but is kinda odd as it involves a cross-filesystem hard link. unwhiteout(2) has more promise I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Or is that a hack of devfs to allow it, and if so does that create any other security problems. Recall the security implications of having procfs's 'file' file. He made a hard link to the file in question, and exposed many different classes of problem: unwanted disclosure, failure to take into account directory permissions, the ability to hard link to the file and execute it later (bad for setuid programs), etc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Or is that a hack of devfs to allow it, [...] Yes, it was a hack, and it will not be hacked that way in my DEVFS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 14760.981228917@critter Poul-Henning Kamp writes: : In message [EMAIL PROTECTED], Warner Losh writes: : In message [EMAIL PROTECTED] Peter Wemm writes: : : As bizzare as it sounds, I like Julian's hack for populating this stuff... : : ie: use a hard link to propagate nodes to the jailed /dev. : : : : eg: mount -t devfs -o empty /home/jail/dev : : ln /dev/null /home/jail/dev/null : : ln /dev/zero /home/jail/dev/zero : : ... : : mount -u -o ro /home/jail/dev : : But you can't do hard links accross file systems. Or is that a hack : of devfs to allow it, [...] : : Yes, it was a hack, and it will not be hacked that way in my DEVFS. I seem to recall talking to you about having symbolic links in your devfs mean something "special" as a way around this problem. No that was another, and probably too avant garde idea Julian and I have discussed: Basically device-drivers create devices in a private namespace, in /dev you link from the filesystem namespace to the private namespace with a kind of symbolic link. It has too many "issues" with standards and VOP's to be viable right now. Doing straight symlinks would not work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message 14918.981230622@critter Poul-Henning Kamp writes:
: Doing straight symlinks would not work.
OK.
The other idea that I had was a cpdev. It would be like a templated
mknod. It would stat the first argument and do a mknod with the
st_rdev from the stat, eg:
#include err.h
#include stdlib.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
int
main(char *argv[], int argc)
{
struct stat sbuf;
if (argc != 3)
errx(1, "usage: cpdev src dst");
if (stat(argv[1], sbuf))
err(1, "stat");
if (!S_ISCHR(sbuf.st_mode))
errx(1, "source must be a character device");
if (mknod(argv[2], sbuf.st_mode, sbuf.st_rdev))
err(1, "mknod");
exit(0);
}
This would mean we could export whatever we wanted from the kernel and
something like this would preserve it. It would mean allowing mknodo
n non-readonly devfs mounts. If there was a cheap way to determine
if the rdev was legitimate, it would be the best way to go. However,
that's the rub with this solution: we need to keep a table of devices
(like major numbers today and export them as major numbers) or we need
to know with certainty that a pointer is good, which traditionally has
had its share of security problems. Well, I suppose that the major
number thing could be a special case of returning a hash as well, but
that still requires a kernel table of some flavor.
Notice I don't bother with major/minor numbers at all, but just use
the raw rdev (which I hope is the right dev to use, since I think
st_dev is the device the filesystem is mounted on) so it doesn't
matter what we export as long as we can swallow what we export.
Of course this does assume that all devfs instances export the same
cookies for the same device.
Warner
P.S. I do hope someone will tell me if this is becoming too
bikeshedish.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Warner Losh writes: In message 14918.981230622@critter Poul-Henning Kamp writes: : Doing straight symlinks would not work. OK. The other idea that I had was a cpdev. It would be like a templated mknod. It would stat the first argument and do a mknod with the st_rdev from the stat, eg: It's really very simple, if I get my way, this will be possible: # rm /dev/null # echo 'OOPS!' # rm -W /dev/null # ls -l /dev/null crw-rw-rw- 1 root wheel2, 2 3 Feb 21:25 /dev/null # mount -t devfs devfs /home/jail/dev # cd /home/jail/dev # rm -f * # rm -W null zero tty console # ls -l crw--- 1 phk wheel0, 0 2 Feb 01:09 console drwxr-xr-x 2 root wheel 0 2 Feb 01:06 fd crw-rw-rw- 1 root wheel2, 2 3 Feb 21:25 null crw-rw-rw- 1 root wheel1, 0 3 Feb 17:27 tty crw-rw-rw- 1 root wheel2, 12 1 Jan 1970 zero # P.S. I do hope someone will tell me if this is becoming too bikeshedish. It is :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Sat, Feb 03, 2001 at 12:32:50PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Peter Wemm writes: : As bizzare as it sounds, I like Julian's hack for populating this stuff... : ie: use a hard link to propagate nodes to the jailed /dev. : : eg: mount -t devfs -o empty /home/jail/dev : ln /dev/null /home/jail/dev/null : ln /dev/zero /home/jail/dev/zero : ... : mount -u -o ro /home/jail/dev But you can't do hard links accross file systems. Actually, you've always been able to do things like this. For example: ln /proc/curproc/file /test on a 3.X machine will produce a hard link to ln in / - it doesn't work any more 'cos /proc/curproc/file is now a soft link. I presume the same thing works with fdescfs. This is actually one nice feature Linux procfs has: I once was asked to look at a Linux box someone had broken into. They'd deleted all the files in /var/log, but hadn't HUPed syslogd - so I just hard linked them all back into place again. Not an every day use, but... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message 18334.980748975@critter Poul-Henning Kamp writes: : 1. Say I want to use DEVFS, what should I change? : : Nothing. Just add DEVFS to your kernel config file. So it updates /dev all by itself? What if I want dev nodes elsewhere in the tree, say for a jail? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED] Julian Elischer writes: : you can't.. what is the major number? : : You don't know because they will be dynamically assigned. : Only the kernel knows. : Eventually, major numbers may go away entirely, (or just be a : comlpetely random meaningless number, present only to keep old : programs like tar() happy). What if I want to create a few devices (eg not all in the system) in a chroot'd environment? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Sun, Jan 28, 2001 at 10:19:34PM -0800, John Baldwin wrote: On 29-Jan-01 John Indra wrote: 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. Hrm... what about some custom entries or symlinks I may have? (/dev/cdrom for instance) -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Steve Ames writes: On Sun, Jan 28, 2001 at 10:19:34PM -0800, John Baldwin wrote: On 29-Jan-01 John Indra wrote: 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. Hrm... what about some custom entries or symlinks I may have? (/dev/cdrom for instance) You can create symlinks in /dev, you cannot mknod there. Create your symlinks in /etc/rc.devfs -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Monday, 29 January 2001 at 16:10:24 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Steve Ames writes: On Sun, Jan 28, 2001 at 10:19:34PM -0800, John Baldwin wrote: On 29-Jan-01 John Indra wrote: 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. Hrm... what about some custom entries or symlinks I may have? (/dev/cdrom for instance) You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Tuesday, 30 January 2001 at 8:37:56 +0600, Boris Popov wrote: On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. I'm assuming that there's a good technical reason for the lack of mknod. It also seems that mkdir doesn't work in devfs. Let's give phk time to wake up and tell us. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Greg Lehey writes: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? The reson for not creating device nodes is that you don't have all the information you'll need to really do it. To find out if you are running on a DEVFS system, look for existence of the sysctl variable "vfs.devfs.generation" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], Boris Popov writes: On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. No, mknod needs to be broken so people fix all drivers to be DEVFS aware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Boris Popov wrote: On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. you can't.. what is the major number? You don't know because they will be dynamically assigned. Only the kernel knows. Eventually, major numbers may go away entirely, (or just be a comlpetely random meaningless number, present only to keep old programs like tar() happy). -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
Greg Lehey wrote: On Tuesday, 30 January 2001 at 8:37:56 +0600, Boris Popov wrote: On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. I'm assuming that there's a good technical reason for the lack of mknod. It also seems that mkdir doesn't work in devfs. Let's give phk time to wake up and tell us. I have no idea why mkdir doesnt' work.. (It worked in the old devfs, but I assume it's just that phk just hasn't had the time yet to do it.) mknod is nonsensical in a world wher the user cannot predict the major number, and where the dev entry is connected to the driver via a pointer inside the kernel rather than an index. (How do you create the pointer? (mknod tty2 c 0xc0123452d 2)?) Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
In message [EMAIL PROTECTED], John Indra writes: I noticed that DEVFS has been the default in GENERIC kernel. I have been -CURRENT tracker for the past couple of months and things like DEVFS is still new to me. Thus, a couple of questions arise and I am very glad if someone want to explain it to me, or maybe point to docs that I should read. 1. Say I want to use DEVFS, what should I change? Nothing. Just add DEVFS to your kernel config file. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: DEVFS newbie...
On 29-Jan-01 John Indra wrote: I noticed that DEVFS has been the default in GENERIC kernel. I have been -CURRENT tracker for the past couple of months and things like DEVFS is still new to me. Thus, a couple of questions arise and I am very glad if someone want to explain it to me, or maybe point to docs that I should read. 1. Say I want to use DEVFS, what should I change? /etc/fstab? Should I nuke the current /dev? Just put it in your kernel config, init(8) will mount it for you automagically. 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. Thanks... /john -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
