Date: Sat, 30 May 1998 23:37:00 +0800 From: Peter Wemm <peter@netplex.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Mike Smith <mike@smith.net.au>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <199805301537.XAA22245@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 30 May 1998 11:37:46 %2B0200." <17376.896521066@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <4005.896514865@time.cdrom.com>, "Jordan K. Hubbard" writes: > >> Because it ain't mounted anyhere. Think: user says: > >> > >> # rm /dev/foo0 > >> <expletive> > >> # mknod /dev/foo0 c ??? > >> > >> What are they going to supply for the dev_t? The numbers are dynamic, > >> so there's no possible reference to them. Even if they weren't, > >> there's no guarantee they'd be able to guess them anyway. > > > >1. Of course the numbers aren't dynamic - for backwards-compatibility > > to even begin to work at the mknod-level, you'd have to preserve > > the old assignments. > > No, the medium to long term goal is to kill dev_t and mknod entirely, > they are a hideous kludge and they are scheduled for demolition. > (The process will take slightly longer than 2 minutes, thank you!) > > Think for a moment about this parallel: > > rm -rf /proc/125 > <expletive> > ???? > > Right ? > > Removing /dev/lpt0 doesn't make sense, it doesn't remove the driver, > it doesn't attach from the hardware, it merely removes the namesticker > from the mailbox. > > Devfs is synthetic and maybe we shouldn't even allow removes in the > first place but a whiteout/undelete solution is the "POLA" choice. > > Alternatively devfs could allow mknod, but ignore the major/minor > numbers given and just "DTRT", that would work also after we have > killed dev_t. Exactly.. mknod() can be made to do something useful, even after there are no dev_t's left. Also, /dev/floppy, /dev/mouse and /dev/cdrom really shouldn't be done with mknod on any system, they are best done with ln or ln -s. I think a nowhiteout mount option would be nice, since 'ls -W' etc can show all the devices that are *really* present. However, I could imagine circumstances where it might be preferable to disable whiteouts, eg: the jail scenario where the mounted node would be overloaded with whiteouts and it would allow a cracker something to gather info about since they could see the whiteouts to find out what hardware/drivers are present. Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805301537.XAA22245>