Re: devfs?
["Brian J. Swetland" <[EMAIL PROTECTED]>] > > I'm interested in mucking about with the devfs stuff a bit -- is there > currently any active developer/maintainer/docs? I grabbed the 4.0 > snapshot from the 17th, installed it, grabbed the kernel sources from > CVS, got stuff building and figured out how to enable DDB (not that > much different from the kdebug environment I'm used to from BeOS). I > figured I'd see if there was any more information than the sources. I see (after digging through some recent list archives) that I missed some discussion of this from as recent as a week ago. Also I notice that devfs does build, is mountable, is mountable, and shows a goodly number of the active devices in my system. Somebody mentioned the issue of figuring out when things change in sysctl/devfs/etc (and please excuse me if we've been here before), but there seem to be two non-polling solutions that are workable (though the second is much more work). Either provide /dev/devchanges or whatnot that interested processes can read (and block on) to receive change events (similar to the Linux cardmgr socket stuff) or provide general node monitoring (where processes can register for notifications for move/modify/remove/directorychanged with some entity that plugs into the vfs layer). The latter has some really neat effects (which BeOS makes heavy use of) generally involving not needing to poll for fs changes (input server node monitors /dev/input/... and sees new mice, etc as they're plugged in, GUI file browser gets events when third parties modify stuff in open windows, etc). Also, if anyone did reply to me over the last day or two, I've been having entertaining mail problems (now resolved) which probably resulted in me missing the reply. Brian -- Brian Swetland - [EMAIL PROTECTED] | "If I have hacked deeper than them, it http://www.frotz.net/swetland/| is because I stand in their trenches." |-- Graham Nelson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
On Sat, Nov 16, 2002 at 10:15:53AM -0500, sven svenskar wrote: > I have server i give people shell accounts each in chroot and they need some >devices. How this work with DEVFS? Should I copy devices from DEVFS with dd or tar? >Or I mount DEVFS in every chroots? Please help! why not just use jail enviornments? -- Kyle Martin || [EMAIL PROTECTED] || http://www.BSDng.org "Profanity is the only language all programmers understand." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, "sven svenskar" writes: >I have server i give people shell accounts each in chroot and they need some devices. >How this work with DEVFS? Should I copy devices from DEVFS with dd or tar? Or I mount >DEVFS in every chroots? Please help! current or stable ? -- 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
On Sat, Nov 16, 2002 at 10:15:53AM -0500, sven svenskar wrote: > I have server i give people shell accounts each in chroot and they need some >devices. How this work with DEVFS? Should I copy devices from DEVFS with dd or tar? >Or I mount DEVFS in every chroots? Please help! why not just use jail enviornments? -- Kyle Martin || [EMAIL PROTECTED] || http://www.BSDng.org "Profanity is the only language all programmers understand." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, Kyle Martin writes: >On Sat, Nov 16, 2002 at 10:15:53AM -0500, sven svenskar wrote: >> I have server i give people shell accounts each in chroot and they need some >devices. How this work with DEVFS? Should I copy devices from DEVFS with dd or tar? >Or I mount DEVFS in every chroots? Please help! You should: 1. use jails instead if you can (you can jail multiple jails on the same IP and it can even be the systems "own" IP). 2. mount devfs in each jail. 3. use devfs(8) to filter which devices you give people access to. 4. contribute your scripts to do all this to the project :-) -- 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
In message <[EMAIL PROTECTED]>, Tony Johnson writes: >I'm sure you know this already, but I just want to reiterate. I have >done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did >a cvsup in the "wee" hours in the morning. I then did make world in >/usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. >The system should be clean. Correct me if I am wrong. If I put "option >DEVFS" in my kernel , build/install that kernel, my computer will not >bot up completely. I will have to enter single user with an errr >message stating "/dev: no such file or directory" Mounting of fstab >filesystems fails. press enter for /bin/sh > >My /dev directory exists. Once I rebuild the kernel with no DEVFS it >all works, but I like devfs as it makes all the device files that i need >for my sound card as an example. Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
Sorry for the repeat. I was playing with the sendmail 8.11.0 you guys have provided... But anyway, if DEVFS is in my fstab or not it gets mounted under /dev , as you point out. I guess this is the problem because I have to remove "options DEVFS" from my kernel in single user for my system to boot. Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Tony Johnson writes: > >I'm sure you know this already, but I just want to reiterate. I have > >done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did > >a cvsup in the "wee" hours in the morning. I then did make world in > >/usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. > >The system should be clean. Correct me if I am wrong. If I put "option > >DEVFS" in my kernel , build/install that kernel, my computer will not > >bot up completely. I will have to enter single user with an errr > >message stating "/dev: no such file or directory" Mounting of fstab > >filesystems fails. press enter for /bin/sh > > > >My /dev directory exists. Once I rebuild the kernel with no DEVFS it > >all works, but I like devfs as it makes all the device files that i need > >for my sound card as an example. > > Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init > will mount devfs on /dev automatically. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
One last note, if this is a case for a functional union fs. I'd like to see my mistyping and the system combine things into one device directory so this type of problem will not stop my system frm booting up completely... Tony Johnson wrote: > > Sorry for the repeat. I was playing with the sendmail 8.11.0 you guys > have provided... > > But anyway, if DEVFS is in my fstab or not it gets mounted under /dev , > as you point out. I guess this is the problem because I have to remove > "options DEVFS" from my kernel in single user for my system to boot. > > Poul-Henning Kamp wrote: > > > > In message <[EMAIL PROTECTED]>, Tony Johnson writes: > > >I'm sure you know this already, but I just want to reiterate. I have > > >done a make world on Fridays and Saturday's Freebsd 5.0-CURRENT. I did > > >a cvsup in the "wee" hours in the morning. I then did make world in > > >/usr/src to rebuild the system, rebuild kernel, and mergemaster -sv. > > >The system should be clean. Correct me if I am wrong. If I put "option > > >DEVFS" in my kernel , build/install that kernel, my computer will not > > >bot up completely. I will have to enter single user with an errr > > >message stating "/dev: no such file or directory" Mounting of fstab > > >filesystems fails. press enter for /bin/sh > > > > > >My /dev directory exists. Once I rebuild the kernel with no DEVFS it > > >all works, but I like devfs as it makes all the device files that i need > > >for my sound card as an example. > > > > Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init > > will mount devfs on /dev automatically. > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Sun, 27 Aug 2000 21:35:26 +0200, Poul-Henning Kamp wrote: > Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init > will mount devfs on /dev automatically. Out of curiosity, what's the motivation behind this decision? Why don't you allow defvs to be mounted on an arbitrary mount point? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > >On Sun, 27 Aug 2000 21:35:26 +0200, Poul-Henning Kamp wrote: > >> Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init >> will mount devfs on /dev automatically. > >Out of curiosity, what's the motivation behind this decision? Why don't >you allow defvs to be mounted on an arbitrary mount point? You can also mount it other places: mount -t devfs foo /usr/jail/jail1/dev (but the "no new devices" feature is not committed yet, I'm still working on it). The reason for mounting it in /sbin/init is historical and possibly wrong but it does have the benefit that it will DTRT for people. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Mon, 28 Aug 2000, Poul-Henning Kamp wrote: > >> Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init > >> will mount devfs on /dev automatically. > > > >Out of curiosity, what's the motivation behind this decision? Why don't > >you allow defvs to be mounted on an arbitrary mount point? > > The reason for mounting it in /sbin/init is historical and possibly > wrong but it does have the benefit that it will DTRT for people. This is necessary for proper synching of the root filesystem. To achieve this effect devfs is mounted over readonly UFS, so when the root filesystem is updated to R/W state it pulls the proper device from devfs filesystem. -- 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
In article <[EMAIL PROTECTED]> you wrote: > With devfs "default" in -current, I have a question about permissions. I > know that rc.devfs will set up custom permissions at boot... But what > about a device that detaches? When you re-attach, it goes back to the > default permissions. This is a bit annoying; is there a workaround for it? > Should this be handled by something that does the re-attaching? At least for the USB devices this can be done with the 'usbd' daemon. N.Dudorov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : At least for the USB devices this can be done with the : 'usbd' daemon. And pccardd can handle this for OLDCARD users. NEWCARD users will need to cope until something comes alone :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: DEVFS
On 10-May-01 Ruslan Ermilov wrote: > Hi! > > Just installed recent -CURRENT on my PC, and noticed strange things: > > 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still > happening on /dev, and where? devfs is mounted by /sbin/init IIRC. > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? Why wouldn't it be? (Granted, it is a bit _weird_). You can do the same with other fs's: > mount -t procfs procfs on /proc (procfs, local) > sudo mount /proc > mount -t procfs procfs on /proc (procfs, local) procfs on /proc (procfs, local) > sudo umount /proc -- 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
Re: DEVFS
On Thu, 10 May 2001, Ruslan Ermilov wrote: > Hi! > > Just installed recent -CURRENT on my PC, and noticed strange things: > > 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still > happening on /dev, and where? Somewhat wierdly and unobviously, it's init that does the magic. > > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? > > perl# mount -t devfs > devfs on /dev (devfs, local) > perl# mount /dev > perl# mount -t devfs > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > perl# mount /dev > perl# mount -t devfs > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > perl# > > > Thanks, > -- > Ruslan ErmilovOracle Developer/DBA, > [EMAIL PROTECTED] Sunbay Software AG, > [EMAIL PROTECTED]FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.orgThe Power To Serve > http://www.oracle.com Enabling The Information Age > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
John Baldwin wrote: > > On 10-May-01 Ruslan Ermilov wrote: > > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? > > Why wouldn't it be? (Granted, it is a bit _weird_). You can do the same with > other fs's: ...and happily shoot yourself in the foot this way. :) I had pretty weird experiences into mounting multiple root directories (!). I have a crappy 486 which has an equally crappy IDE controller which can't grok my 3.2G HD. The loader couldn't boot the kernel from the drive. I had to keep another very crappy 250M HD with a duplicate of the / filesystem and a very special kernel that mounted its root from the other drive, since the kernel could recognize the drive correctly. Without DMA, of course. :) But it works. My point here is that I had a lot of fun in totally scrapping my system by doing a spurious mount /. No reboot(1) or halt(1) available... ;) C-A-Del! Anyways... Another OT question.. Is any MFC planned for devfs? I'm getting jealous of -current (running -stable). ;) Thanks, A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, Ruslan Ermilov writes: >Hi! > >Just installed recent -CURRENT on my PC, and noticed strange things: > >1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still >happening on /dev, and where? It's done as the first thing in /sbin/init to make sure all device access is done through DEVFS. > >2) Is it valid that multiple DEVFS mounts over /dev are allowed? yes. -- 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
In message <[EMAIL PROTECTED]>, Matthew Jacob writes: > > >On Thu, 10 May 2001, Ruslan Ermilov wrote: > >> Hi! >> >> Just installed recent -CURRENT on my PC, and noticed strange things: >> >> 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still >> happening on /dev, and where? > >Somewhat wierdly and unobviously, it's init that does the magic. this is basically because it is one line to do it in /sbin/init, but about 100 to do it in the kernel. Blame the poor design of mount(2) (and ask Adrian when he fixes it :-) -- 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
In message <[EMAIL PROTECTED]>, "Antoine Beaupre (LMC)" writes: >Another OT question.. Is any MFC planned for devfs? I'm getting jealous >of -current (running -stable). ;) It will not be MFC'ed unless somebody else does the work, I simply don't have the time... -- 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
On Fri, 11 May 2001, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Matthew > Jacob writes: > > > > > >On Thu, 10 May 2001, Ruslan Ermilov wrote: > > > >> Hi! > >> > >> Just installed recent -CURRENT on my PC, and noticed strange things: > >> > >> 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still > >> happening on /dev, and where? > > > >Somewhat wierdly and unobviously, it's init that does the magic. > > this is basically because it is one line to do it in /sbin/init, > but about 100 to do it in the kernel. > > Blame the poor design of mount(2) (and ask Adrian when he fixes > it :-) It must be the excellent design of mount(2) that makes it so easy to do things with it where it can be used :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, Bruce Evan s writes: >> Blame the poor design of mount(2) (and ask Adrian when he fixes >> it :-) > >It must be the excellent design of mount(2) that makes it so easy to >do things with it where it can be used :-). Just too bad it wasn't designed so that it can be used from kernel processes as well :-( -- 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
On Fri, 11 May 2001, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evan > s writes: > > >> Blame the poor design of mount(2) (and ask Adrian when he fixes > >> it :-) > > > >It must be the excellent design of mount(2) that makes it so easy to > >do things with it where it can be used :-). > > Just too bad it wasn't designed so that it can be used from kernel > processes as well :-( I've made this observation before, of course, but it is my general opionion that, leaving aside uio structures, awareness of "userland" data pointers should generall be limited to the system call code rather than the service implementation. The existence of userland points in VFS calls (and I've introduced one myself in the vfs_extattrctl call) is generally evil. It makes it much harder to initiate a service from within a kernel thread or process, and do ABI wrapping. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >On Fri, 11 May 2001, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Bruce Evan >> s writes: >> >> >> Blame the poor design of mount(2) (and ask Adrian when he fixes >> >> it :-) >> > >> >It must be the excellent design of mount(2) that makes it so easy to >> >do things with it where it can be used :-). >> >> Just too bad it wasn't designed so that it can be used from kernel >> processes as well :-( > >I've made this observation before, of course, but it is my general >opionion that, leaving aside uio structures, awareness of "userland" data >pointers should generall be limited to the system call code rather than >the service implementation. The existence of userland points in VFS calls >(and I've introduced one myself in the vfs_extattrctl call) is generally >evil. It makes it much harder to initiate a service from within a kernel >thread or process, and do ABI wrapping. Well, if I'm not allowed to gripe about that (although in reality you agree with me :-) then I'll gripe about the "max 32 mount options" limitation. -- 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
In message <[EMAIL PROTECTED]>, "David W. Chapman Jr." writes: >If I'm using devfs on -current, can I erase the contents of my /dev >before devfs is mounted to save space? Yes, the easiest way is: boot singleuser mount -o rw / mv /dev /dev_ mkdir /dev chmod 755 /dev reboot ... rm -rf /dev_ -- 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
On Sat, 18 Aug 2001, David W. Chapman Jr. wrote: > If I'm using devfs on -current, can I erase the contents of my /dev > before devfs is mounted to save space? You could, but that would be, well, it'd really be a Darwin award winner. > > -- > David W. Chapman Jr. > [EMAIL PROTECTED] Raintree Network Services, Inc. > [EMAIL PROTECTED] FreeBSD Committer > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
Ohh, I think doing this unwise. You should always leave yourself something in /dev... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Sat, 18 Aug 2001, David W. Chapman Jr. wrote: >If I'm using devfs on -current, can I erase the contents of my /dev >before devfs is mounted to save space? What space are you planning to save? You might free up some inodes but according to my 4.4-PRERELEASE box: [bandix@leto /dev]% du -sh . 58K. -- "Never put off until tomorrow what you can do today. There might be a law against it by that time." -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Sun, Aug 19, 2001 at 07:50:31PM -0400, Brandon D. Valentine wrote: > On Sat, 18 Aug 2001, David W. Chapman Jr. wrote: > > >If I'm using devfs on -current, can I erase the contents of my /dev > >before devfs is mounted to save space? > > What space are you planning to save? You might free up some inodes but > according to my 4.4-PRERELEASE box: > > [bandix@leto /dev]% du -sh . > 58K. > Hrm, mine said 5.5M. I did say this machine had been around since 2.2.8, right? I still had raw devices in there I believe. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
In message <[EMAIL PROTECTED]> "David W. Chapman Jr." writes: : Hrm, mine said 5.5M. I did say this machine had been around since : 2.2.8, right? I still had raw devices in there I believe. That's at least 5.0M too big. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Sun, Aug 19, 2001 at 10:11:35PM -0500, David W. Chapman Jr. wrote: > On Sun, Aug 19, 2001 at 07:50:31PM -0400, Brandon D. Valentine wrote: > > On Sat, 18 Aug 2001, David W. Chapman Jr. wrote: > > > > >If I'm using devfs on -current, can I erase the contents of my /dev > > >before devfs is mounted to save space? > > > > What space are you planning to save? You might free up some inodes but > > according to my 4.4-PRERELEASE box: > > > > [bandix@leto /dev]% du -sh . > > 58K. > > > Hrm, mine said 5.5M. I did say this machine had been around since > 2.2.8, right? I still had raw devices in there I believe. Devices are just inodes..you shouldn't have anything in /dev other than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. You probably have some other file in there which was accidentally created by something like # verbosecommand > /dev/nlul :-) Kris PGP signature
Re: devfs
On Sun, 19 Aug 2001, Kris Kennaway wrote: >Devices are just inodes..you shouldn't have anything in /dev other >than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. >You probably have some other file in there which was accidentally >created by something like > ># verbosecommand > /dev/nlul The following command should reveal the culprit: du -h /dev/* | grep -v 0B -- "Never put off until tomorrow what you can do today. There might be a law against it by that time." -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote: > On Sun, 19 Aug 2001, Kris Kennaway wrote: > > >Devices are just inodes..you shouldn't have anything in /dev other > >than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. > >You probably have some other file in there which was accidentally > >created by something like > > > ># verbosecommand > /dev/nlul > > The following command should reveal the culprit: > du -h /dev/* | grep -v 0B > The only problem is devfs is mounted and I can't seem to get around that. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: >The only problem is devfs is mounted and I can't seem to get around >that. I haven't had much time lately to fool with my -CURRENT box but it seems that booting singleuser oughta help? -- "Never put off until tomorrow what you can do today. There might be a law against it by that time." -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
At 11:17 AM 8/20/2001 -0400, Brandon D. Valentine wrote: >On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: > >>The only problem is devfs is mounted and I can't seem to get around >>that. > >I haven't had much time lately to fool with my -CURRENT box but >it seems that booting singleuser oughta help? > >-- >"Never put off until tomorrow what you can do today. There might be a >law against it by that time." -- /usr/games/fortune, 07/30/2001 > >Brandon D. Valentine > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message I couldn't do this from single user. I forget the error somthing about moving a mount point. What worked for me was to boot off the CDROM and go into the fixit mode then mount the / partition on /mnt. cd /mnt/dev/ rm -r * Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote: > On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: > > >The only problem is devfs is mounted and I can't seem to get around > >that. > > I haven't had much time lately to fool with my -CURRENT box but > it seems that booting singleuser oughta help? > Already tried that, still mounts devfs immediately. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
Hmm- this is because init gets the 'd' argument if devfs is linked into the kernel with the variable 'devfs_present' set. Isn't there a way for the loader to dork with this? On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: > On Mon, Aug 20, 2001 at 11:17:42AM -0400, Brandon D. Valentine wrote: > > On Mon, 20 Aug 2001, David W. Chapman Jr. wrote: > > > > >The only problem is devfs is mounted and I can't seem to get around > > >that. > > > > I haven't had much time lately to fool with my -CURRENT box but > > it seems that booting singleuser oughta help? > > > Already tried that, still mounts devfs immediately. > -- > David W. Chapman Jr. > [EMAIL PROTECTED] Raintree Network Services, Inc. > [EMAIL PROTECTED] FreeBSD Committer > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Mon, Aug 20, 2001 at 08:02:44AM -0500, David W. Chapman Jr. wrote: > On Mon, Aug 20, 2001 at 02:05:06AM -0400, Brandon D. Valentine wrote: > > On Sun, 19 Aug 2001, Kris Kennaway wrote: > > > > >Devices are just inodes..you shouldn't have anything in /dev other > > >than MAKEDEV, the fd/ subdirectory and a whole bunch of device nodes. > > >You probably have some other file in there which was accidentally > > >created by something like > > > > > ># verbosecommand > /dev/nlul > > > > The following command should reveal the culprit: > > du -h /dev/* | grep -v 0B > > > The only problem is devfs is mounted and I can't seem to get around > that. Boot single-user. Kris PGP signature
Re: devfs configuration
Attila Nagy <[EMAIL PROTECTED]> wrote: > Hello, > > Is there a recommended way to configure multiple devfs rules (massive jail > usage) in a standard manner? I don't see any traces of it. > Or is it up to the user how does he manage this question, for example a > shell script with the rules? There is currently no "standard" way to do this. I described a way it might be implemented to freebsd-arch some time ago, but I recieved very few comments, and have not implemented it due to lack of time. The proposal is here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2002/freebsd-arch/20020804.freebsd-arch If that mechanism can be used to do what you want (I think it can be), and you end up implementing it, I will gladly help get it into the tree. Thanks, Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs configuration
On Fri, 10 Jan 2003, Attila Nagy wrote:
> Is there a recommended way to configure multiple devfs rules (massive jail
> usage) in a standard manner? I don't see any traces of it.
> Or is it up to the user how does he manage this question, for example a
> shell script with the rules?
If you are using devfs in jail, then following patch to current
(by Dima Dorfman <[EMAIL PROTECTED]>) is extremely useful. Allows tules
to work on symlinks (for example /dev/urandom is symlink and ssh works
better if it is present).
best regards,
taavi
Index: devfs_rule.c
===
RCS file: /a/ncvs/src/sys/fs/devfs/devfs_rule.c,v
retrieving revision 1.3
diff -u -r1.3 devfs_rule.c
--- devfs_rule.c8 Oct 2002 04:21:54 - 1.3
+++ devfs_rule.c2 Dec 2002 21:20:04 -
@@ -634,7 +634,8 @@
dev = devfs_rule_getdev(de);
if (dev != NULL)
pname = dev->si_name;
- /* XXX: Support symlinks (check d_type == DT_LNK here). */
+ else if (de->de_dirent->d_type == DT_LNK)
+ pname = de->de_dirent->d_name;
else
return (0);
KASSERT(pname != NULL, ("devfs_rule_matchpath: NULL pname"));
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs configuration
Taavi Talvik <[EMAIL PROTECTED]> wrote: > On Fri, 10 Jan 2003, Attila Nagy wrote: > > > Is there a recommended way to configure multiple devfs rules (massive jail > > usage) in a standard manner? I don't see any traces of it. > > Or is it up to the user how does he manage this question, for example a > > shell script with the rules? > > If you are using devfs in jail, then following patch to current > (by Dima Dorfman <[EMAIL PROTECTED]>) is extremely useful. Allows tules > to work on symlinks (for example /dev/urandom is symlink and ssh works > better if it is present). Oops, I forgot to commit that, didn't I? Rectified now in -CURRENT, but you'll still need to apply it if you're running RELENG_5_0. Thanks for the reminder. Dima. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs question
On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: > >Oops, error on my part; /proc does need to exist. So, I guess the > >question is this: Can devfs's error handling in the case of /dev being > >non-existant be improved? > > Barely, because without /dev, how do you plan to open the console ? > > Mkdir(/dev) isn't an option because the rootfs is mounted R/O. > > About the only thing one could do is make init exit(bla) and get > a diagnostic from the kernel. It may make sense to do that. An error message would be sufficient; my concern was that someone might run into this and spend hours trying to figure out which of X variables was the problem. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs question
In message <[EMAIL PROTECTED]>, Mike Silbersack w rites: > >On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: > >> >Oops, error on my part; /proc does need to exist. So, I guess the >> >question is this: Can devfs's error handling in the case of /dev being >> >non-existant be improved? >> >> Barely, because without /dev, how do you plan to open the console ? >> >> Mkdir(/dev) isn't an option because the rootfs is mounted R/O. >> >> About the only thing one could do is make init exit(bla) and get >> a diagnostic from the kernel. It may make sense to do that. > >An error message would be sufficient; my concern was that someone >might run into this and spend hours trying to figure out which of X >variables was the problem. Right, but the only way to get an error message is to let /sbin/init die and have the kernel print the message. /sbin/init cannot print the message when there is no "/dev/console" can it ? -- 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 question
On Sat, 27 Oct 2001, Poul-Henning Kamp wrote: > >An error message would be sufficient; my concern was that someone > >might run into this and spend hours trying to figure out which of X > >variables was the problem. > > Right, but the only way to get an error message is to let /sbin/init > die and have the kernel print the message. /sbin/init cannot > print the message when there is no "/dev/console" can it ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'm in over my head on this one; I really don't know anything about the boot process. Having init die if there's no /dev sounds acceptable to me. After all, if there's no /dev, the system looks like it's in trouble. (If this does not make sense, reference above paragraph.) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs question
Poul-Henning Kamp <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]>, Mike Silbersack writes: > > Oops, error on my part; /proc does need to exist. So, I guess the > > question is this: Can devfs's error handling in the case of /dev being > > non-existant be improved? > Barely, because without /dev, how do you plan to open the console ? > > Mkdir(/dev) isn't an option because the rootfs is mounted R/O. You could modify devfs so it can be union-mounted on top of /; or you could hack namei to return a fake vnode for /dev so it's always present. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs question
< said: > Right, but the only way to get an error message is to let /sbin/init > die and have the kernel print the message. /sbin/init cannot > print the message when there is no "/dev/console" can it ? Yes, it can, if the kernel does the right then when hand-crafting the `init' process to ensure that the console is already open rather than making `init' do it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs question
In message <[EMAIL PROTECTED]>, Garrett Wollman w rites: >< said: > >> Right, but the only way to get an error message is to let /sbin/init >> die and have the kernel print the message. /sbin/init cannot >> print the message when there is no "/dev/console" can it ? > >Yes, it can, if the kernel does the right then when hand-crafting the >`init' process to ensure that the console is already open rather than >making `init' do it. Not a bad idea, but currently not implemented. -- 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 question
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes: >Poul-Henning Kamp <[EMAIL PROTECTED]> writes: >> In message <[EMAIL PROTECTED]>, Mike Silbersack >writes: >> > Oops, error on my part; /proc does need to exist. So, I guess the >> > question is this: Can devfs's error handling in the case of /dev being >> > non-existant be improved? >> Barely, because without /dev, how do you plan to open the console ? >> >> Mkdir(/dev) isn't an option because the rootfs is mounted R/O. > >You could modify devfs so it can be union-mounted on top of /; or you >could hack namei to return a fake vnode for /dev so it's always >present. Right, but then again, I could also stay sane :-) -- 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 oddity?
In message <[EMAIL PROTECTED]>, Steve Kargl w rites: >root[208] cdcontrol play >cdcontrol: no CD device name specified, defaulting to /dev/cd0c >cdcontrol: /dev/cd0cc: No such file or directory > >Why is an extra "c" appended to cd0c? That's not devfs, that's cdcontrol. It should be fixed to use /dev/cd0 and not try to append 'c', there are not, and have probably never been BSD disklabels on enough disks to warrant this hack. -- 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 oddity?
On Sun, Oct 06, 2002 at 12:19:46AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Steve Kargl w > rites: > >root[208] cdcontrol play > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c > >cdcontrol: /dev/cd0cc: No such file or directory > > > >Why is an extra "c" appended to cd0c? > > That's not devfs, that's cdcontrol. > > It should be fixed to use /dev/cd0 and not try to append 'c', > there are not, and have probably never been BSD disklabels > on enough disks to warrant this hack. > Okay. This just started with a kernel built from sources of Friday vintage (without GEOM). My previous kernel from Sun Sep 8 08:53:47 PDT 2002 does not have this problem. Building and running a kernel in the the time between and Sep 8 and new has been an adventure. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
On Sat, Oct 05, 2002 at 03:39:47PM -0700, Steve Kargl wrote:
> On Sun, Oct 06, 2002 at 12:19:46AM +0200, Poul-Henning Kamp wrote:
> > In message <[EMAIL PROTECTED]>, Steve Kargl w
> > rites:
> > >root[208] cdcontrol play
> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c
> > >cdcontrol: /dev/cd0cc: No such file or directory
> > >
> > >Why is an extra "c" appended to cd0c?
> >
> > That's not devfs, that's cdcontrol.
> >
> > It should be fixed to use /dev/cd0 and not try to append 'c',
> > there are not, and have probably never been BSD disklabels
> > on enough disks to warrant this hack.
> >
>
> Okay. This just started with a kernel built from
> sources of Friday vintage (without GEOM). My previous
> kernel from Sun Sep 8 08:53:47 PDT 2002 does not have
> this problem. Building and running a kernel in the
> the time between and Sep 8 and new has been an adventure.
>
This appears to fix the problem.
--
Steve
--- cdcontrol.c.origSat Oct 5 16:05:23 2002
+++ cdcontrol.c Sat Oct 5 16:07:36 2002
@@ -51,11 +51,7 @@
#define ASTS_VOID 0x15 /* No current audio status to return */
#ifndef DEFAULT_CD_DRIVE
-# define DEFAULT_CD_DRIVE "/dev/cd0c"
-#endif
-
-#ifndef DEFAULT_CD_PARTITION
-# define DEFAULT_CD_PARTITION "c"
+# define DEFAULT_CD_DRIVE "/dev/cd0"
#endif
#define CMD_DEBUG 1
@@ -1249,11 +1245,6 @@
}
fd = open (devbuf, O_RDONLY);
-
- if (fd < 0 && errno == ENOENT) {
- strcat (devbuf, DEFAULT_CD_PARTITION);
- fd = open (devbuf, O_RDONLY);
- }
if (fd < 0) {
if (errno == ENXIO) {
--- cdcontrol.1.origSat Oct 5 16:07:57 2002
+++ cdcontrol.1 Sat Oct 5 16:08:53 2002
@@ -37,15 +37,13 @@
Print as much information as possible.
.It Fl f Ar device
Specify a device, such as
-.Pa /dev/cd0c
+.Pa /dev/cd0
or
.Pa mcd0 .
Both absolute path and relative to
.Pa /dev
filename are possible.
Suffix
-.Pa c
-is added to the device name if needed.
.El
.Pp
The available commands are listed below.
@@ -183,10 +181,10 @@
.Ev CDROM .
.El
.Sh FILES
-.Bl -tag -width ".Pa /dev/mcd0c" -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width ".Pa /dev/mcd0" -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
.El
.Sh AUTHORS
.An Jean-Marc Zucconi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
On Sat, 5 Oct 2002, Steve Kargl wrote: > > In message <[EMAIL PROTECTED]>, Steve Kargl w > > rites: > > >root[208] cdcontrol play > > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c > > >cdcontrol: /dev/cd0cc: No such file or directory > > > > > >Why is an extra "c" appended to cd0c? The first "c" is part of the standard name for the whole of a (labelled) disk device. phk is busily breaking this standard. The second "c" is because cdcontrol tries tacking on a "c" in case the user forgot it. Here the user didn't specify a device name, so the default of "cd0c" was tried, and since that was broken recently, it doesn't work, and a "c" is tacked on to it. The user can work around this easily enough by specifying the device, except in the !DEVFS case when the device doesn't exist. > Okay. This just started with a kernel built from > sources of Friday vintage (without GEOM). My previous > kernel from Sun Sep 8 08:53:47 PDT 2002 does not have > this problem. Building and running a kernel in the > the time between and Sep 8 and new has been an adventure. This is because rev.1.62 of scsi_cd.c axed labelling support. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Sat, 5 Oct 2002, Steve Kargl wrote: > >> > In message <[EMAIL PROTECTED]>, Steve Kargl w >> > rites: >> > >root[208] cdcontrol play >> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c >> > >cdcontrol: /dev/cd0cc: No such file or directory >> > > >> > >Why is an extra "c" appended to cd0c? > >The first "c" is part of the standard name for the whole of a (labelled) >disk device. It's not any "standard name". It is a convention used on a minority of UNIX platforms out there, and it is certainly not "standard" even for BSD based systems. It is also illogical, counter-intuitive and prone to mistakes. -- 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 oddity?
On Sun, 6 Oct 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >On Sat, 5 Oct 2002, Steve Kargl wrote: > > > >> > In message <[EMAIL PROTECTED]>, Steve Kargl w > >> > rites: > >> > >root[208] cdcontrol play > >> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c > >> > >cdcontrol: /dev/cd0cc: No such file or directory > >> > > > >> > >Why is an extra "c" appended to cd0c? > > > >The first "c" is part of the standard name for the whole of a (labelled) > >disk device. > > It's not any "standard name". It is a convention used on a minority > of UNIX platforms out there, and it is certainly not "standard" even > for BSD based systems. It is a standard convention in FreeBSD-4, NetBSD and OpenBSD. Except the partition letter is actually "d" in NetBSD and OpenBSD for i386's and a few other arches. > It is also illogical, counter-intuitive and prone to mistakes. That may be, but changing it without even preparing for the change breaks POLA. This consideration prevented me from axing partitions soon after I implemented slices. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
On Sun, Oct 06, 2002 at 08:29:52AM +0200, Poul-Henning Kamp wrote: > >The first "c" is part of the standard name for the whole of a (labelled) > >disk device. > > It's not any "standard name". It is a convention used on a minority > of UNIX platforms out there, and it is certainly not "standard" even > for BSD based systems. Since when hasn't it been standard on BSD based systems? Other than recently on FreeBSD, all other BSD systems I've used, the "c" partition has been necessary when wanting to operate on the entire disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
On Sun, 6 Oct 2002, David O'Brien wrote: > Since when hasn't it been standard on BSD based systems? Other than > recently on FreeBSD, all other BSD systems I've used, the "c" partition > has been necessary when wanting to operate on the entire disk. Has our CDROM driver ever supported multiple ISO filesystems per CD? Has it supported multi-session CDROMs? The notion of partitions on CDROMs is a little ambiguous. I'm hoping that GEOM can improve this. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
In message <[EMAIL PROTECTED]>, "Matthew N. Dodd" w rites: >On Sun, 6 Oct 2002, David O'Brien wrote: >> Since when hasn't it been standard on BSD based systems? Other than >> recently on FreeBSD, all other BSD systems I've used, the "c" partition >> has been necessary when wanting to operate on the entire disk. > >Has our CDROM driver ever supported multiple ISO filesystems per CD? Has >it supported multi-session CDROMs? The notion of partitions on CDROMs is >a little ambiguous. I'm hoping that GEOM can improve this. I'm not sure GEOM could improve it as much as atapi-cd already has improved it, I'm not sure where it is documented, but you can access each track separately with some /dev/acd0t%d kind of syntax or something. -- 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 oddity?
> >> > In message <[EMAIL PROTECTED]>, Steve Kargl w > >> > rites: > >> > >root[208] cdcontrol play > >> > >cdcontrol: no CD device name specified, defaulting to /dev/cd0c > >> > >cdcontrol: /dev/cd0cc: No such file or directory > >> > > > >> > >Why is an extra "c" appended to cd0c? > > > >The first "c" is part of the standard name for the whole of a (labelled) > >disk device. > > It's not any "standard name". It is a convention used on a minority > of UNIX platforms out there, and it is certainly not "standard" even > for BSD based systems. It's certainly standard on every BSD based system I've ever used, which goes *WAY* back. (Every BSD OS vendor has done it this way, including Sun, DEC, HP, etc...) > It is also illogical, counter-intuitive and prone to mistakes. Then every standard is the same, since standards by their very nature are illogical. Doing something the same way is illogical? (If you haven't figured it out, I disagree *strongly* with the above statement.) > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe ^^^ Which also used 'c' as the entire 'whole' of a labelled disk device. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs oddity?
< said: > Has our CDROM driver ever supported multiple ISO filesystems per CD? Has > it supported multi-session CDROMs? The notion of partitions on CDROMs is > a little ambiguous. I'm hoping that GEOM can improve this. Sort of, but it often gets things wrong for the more interesting CD-ROM types. I've never had it work correctly with Photo CDs, for example; I'm always stuck doing successive `mount_cd9660 -o 12345' until I find the one that actually works (as opposed to the one the code chooses automatically, which never has a valid filesystem on it). -GAWollman 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
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 <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...
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 <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. As you know, but others might not, the device name space is flat an unique (well, except for maybe /dev/fd, which is just unique and can be viewed as flat for the purposes of this discussion). As such, ln -s /dev/null /jail/dev/null could also be expressed as ln -s null /jail/dev/null. The symlink means not "follow this filesystem name space link" but instead "lookup this device name in your device namespace table." But I'm not sure that would work (being only dimly aware of the details of vfs layers and all). Nor am I sure about all the security implications of it (I'm not seeing any at the moment, since you could mount it empty, do the symlinks then remount it r/o). 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 <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
#include
#include
#include
#include
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 behaviour
On Thu, Jul 05, 2001 at 07:57:41AM +0200, Riccardo Torrini wrote: > Maybe this is a stupid(?) question, but how DEVFS is supposed > to work with softlink? How can I make them reboot-resistant? > See /etc/rc.devfs (which should probably be referenced in devfs(5)). -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org PGP signature
Re: DEVFS related message
In message <[EMAIL PROTECTED]>, Munehiro Matsuda writ es: >Hi All, > >I just got following DEVFS related message with >this mornings current. > >DEVFS Overflow table with 32768 entries allocated when 925 in use > >Anybody seen this? This is mostly harmless. When DEVFS initially was integrated the locking situation was rather tricky and malloc failures therefor not easy to handle. Therefore DEVFS uses a compile time array of pointers to its inodes. If this table seems to be running out, (less than 100 free entries) an "overflow" table will be attempted allocated which can contain more entries. You can adjust both the regular and the overflow table sizes with compile time constants NDEVFSINO and NDEVFSOVERFLOW. When more of the kernel has been de-Giantized, this code can be revisited and these constants can probably be eliminated. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes : >I've checked the manpages, the files in /etc, and Googled, and I can't >find the answer. I am begining to worry there isn't one. How does one >change the permissions on dynamically created devices? That is, when >the node comes into existence, it has the permissions I want, and not >necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). -- 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(5) Permissions
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote: > How does one change the permissions on dynamically created > devices? That is, when the node comes into existence, it has > the permissions I want, and not necessarily the defaults. You can (must?) use /etc/rc.devfs [...] # Setup DEVFS, ie permissions, links etc. [...] Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote:
> On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
>
> > How does one change the permissions on dynamically created
> > devices? That is, when the node comes into existence, it has
> > the permissions I want, and not necessarily the defaults.
>
> You can (must?) use /etc/rc.devfs
>
> [...]
> # Setup DEVFS, ie permissions, links etc.
> [...]
I think some people missed the point of the earlier question. My
problem is with devices that are created dynamically as they get
used.
I can put,
chmod 640 /dev/bpf{0,1,2,3}
In rc.devfs, and I will have joy for the first four bpf(4)
devices. That command creates them and gives them the permissions I
want. However, once someone tries to use /dev/bpf4, a new device is
dynamically created with the default permissions, not the permissions
I want.
But creating 'n' devices at boot will do for now (especially since we
used to be restricted to 'n' bpf(4) devices in the kernel
configuration, so it almost resembles historic behavior).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
On 03-Mar-2002 (17:02:35/GMT) Crist J. Clark wrote: > I think some people missed the point of the earlier question. I'm really sorry :( Next time I'll double read the messages. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes > : > >I've checked the manpages, the files in /etc, and Googled, and I can't > >find the answer. I am begining to worry there isn't one. How does one > >change the permissions on dynamically created devices? That is, when > >the node comes into existence, it has the permissions I want, and not > >necessarily the defaults. > > The overall plan is that it will be possible to push a ruleset into > the kernel which changes the defaults. ETA: this summer (If I have to > do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes >> : >> >I've checked the manpages, the files in /etc, and Googled, and I can't >> >find the answer. I am begining to worry there isn't one. How does one >> >change the permissions on dynamically created devices? That is, when >> >the node comes into existence, it has the permissions I want, and not >> >necessarily the defaults. >> >> The overall plan is that it will be possible to push a ruleset into >> the kernel which changes the defaults. ETA: this summer (If I have to >> do it, if somebody wants to help code it it can probably be done faster). > >I have a very similar problem trying to sync my Handspring Visor >as a regular user 'cos the devices only come into existance when >you press the sync button. > >Do you have any designs for this ruleset stuff? From what you said >at BSDconEurope it will have to be fairly complicated to achieve >the your aim of being better than a static permission for a given >device. Not really, the basic idea is just a linked list of rules: name=="/dev/uscanner*" -> chmod 0644 driver=="bpf" -> chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) >Otherwise, one option would just be to have devfs check for a file >in the /dev directory it is mounted over and then use that files >permissions as a default. That would at least get us back the >features of the old /dev which we're missing now. This is much harder than you 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(5) Permissions
> >Do you have any designs for this ruleset stuff? From what you said > >at BSDconEurope it will have to be fairly complicated to achieve > >the your aim of being better than a static permission for a given > >device. > Not really, the basic idea is just a linked list of rules: > name=="/dev/uscanner*" -> chmod 0644 > driver=="bpf" -> chown user > It's not too much work, I just havn't had the time for it yet. > (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: "plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday". I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? > >Otherwise, one option would just be to have devfs check for a file > >in the /dev directory it is mounted over and then use that files > >permissions as a default. That would at least get us back the > >features of the old /dev which we're missing now. > This is much harder than you think... I didn't for a moment think it might be easy ;-) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >> Not really, the basic idea is just a linked list of rules: > >> name=="/dev/uscanner*" -> chmod 0644 >> driver=="bpf" -> chown user > >> It's not too much work, I just havn't had the time for it yet. >> (Junior Kernel Hackers can apply here :-) > >OK - I thought you had something much more complex in mind after >your example: "plugging the nuclear reactor into the serial port >where you had a a modem plugged in yesterday". No, that was to show why "persistence" is a bad idea. >I presume you'd push the rules in using sysclt or did you have >something more filesystem like in mind? Nope, just a sysctl. -- 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(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: > >OK - I thought you had something much more complex in mind after > >your example: "plugging the nuclear reactor into the serial port > >where you had a a modem plugged in yesterday". > > No, that was to show why "persistence" is a bad idea. Fortune(6), anyone?:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, David Malone writes:
> >On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes
> >> :
> >> >I've checked the manpages, the files in /etc, and Googled, and I can't
> >> >find the answer. I am begining to worry there isn't one. How does one
> >> >change the permissions on dynamically created devices? That is, when
> >> >the node comes into existence, it has the permissions I want, and not
> >> >necessarily the defaults.
> >>
> >> The overall plan is that it will be possible to push a ruleset into
> >> the kernel which changes the defaults. ETA: this summer (If I have to
> >> do it, if somebody wants to help code it it can probably be done faster).
> >
> >I have a very similar problem trying to sync my Handspring Visor
> >as a regular user 'cos the devices only come into existance when
> >you press the sync button.
> >
> >Do you have any designs for this ruleset stuff? From what you said
> >at BSDconEurope it will have to be fairly complicated to achieve
> >the your aim of being better than a static permission for a given
> >device.
>
> Not really, the basic idea is just a linked list of rules:
>
> name=="/dev/uscanner*" -> chmod 0644
> driver=="bpf" -> chown user
In the mean while they could temporarily hack their kernels to add the following
code to tty_pty.c.
(not tested)
static int pty_default_owner_uid;
static int
pty_default_owner(SYSCTL_HANDLER_ARGS)
{
int error;
int val;
val = pty_default_owner_uid;
error = sysctl_handle_int(oidp, &val, sizeof(int), req);
if (error != 0 || req->newptr == NULL)
return (error);
if (your_favoutite_sanity_check(val)) {
pty_default_owner_uid = val;
}
return (0);
}
SYSCTL_PROC(_kern, OID_AUTO, pty_default_owner, CTLTYPE_INT | CTLFLAG_RW,
0, sizeof(int), pty_set_owner_uid, "I", "owner for newly created ptys");
and then use pty_default_owner_uid in the make_dev() call.
>
> It's not too much work, I just havn't had the time for it yet.
> (Junior Kernel Hackers can apply here :-)
>
> >Otherwise, one option would just be to have devfs check for a file
> >in the /dev directory it is mounted over and then use that files
> >permissions as a default. That would at least get us back the
> >features of the old /dev which we're missing now.
>
> This is much harder than you 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
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
I've often thought that owner, group, and mode should be defaulted in the registration process for the device. This would let defaults be set in the source code, so in the worst case, you can rebuild the kernel to get them. This would also allow low granularity persistance to be handled in teh same way that kernel visual configuration handles it, or by minimally permitting modification of the data section of the kernel binary. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: > >I presume you'd push the rules in using sysclt or did you have > >something more filesystem like in mind? > > Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: >> >I presume you'd push the rules in using sysclt or did you have >> >something more filesystem like in mind? >> >> Nope, just a sysctl. > >I guess then you just need a sysctl which lets you read the rules >for a given devfs mount point and another which lets you set the >rules for a given defvs mount point. I don't know if we also need >a global ruleset which is applied if the mount point speficic rules >fail to match. True, forgot that. In that case lets make them a mount option using mux@ new nmount(2) systemcall. >The rules should be able to chmod and chown the nodes. Should it >also be able to prevent the creation matching nodes also? Yes. >You mentioned matching on the names drivers and nodes. Are there >any other sorts of matching we are likely to need? Ideally I would want to match on names, driver names and types, ie: name=="ttyd0", driver=="sio" and type=="tty", but I think the important thing here is to make it exensible in the future. -- 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
