From owner-freebsd-hackers Wed Oct 16 22:12:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA04522 for hackers-outgoing; Wed, 16 Oct 1996 22:12:51 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA04516 for ; Wed, 16 Oct 1996 22:12:48 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.6/8.7.3) with SMTP id WAA00909; Sun, 13 Oct 1996 22:06:31 -0700 (PDT) Message-ID: <3265BE95.167EB0E7@whistle.com> Date: Wed, 16 Oct 1996 22:05:25 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Nate Williams CC: Terry Lambert , "Jordan K. Hubbard" , jehamby@lightside.com, jsigmon@www.hsc.wvu.edu, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 2.2.x release question References: <1295.845515554@time.cdrom.com> <199610170235.TAA04604@phaeton.artisoft.com> <199610170423.WAA15646@rocky.mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams wrote: > > > I'm going to be committing code to the FreeBSD source tree that will > enable new and wonderful laptop support. This will allow most laptops > to work wonderfully, modulo a few bugs, but it's a step in the right > direction and it's 'the direction' we need to take in FreeBSD. > > However, it will certainly break existing support for most desktop users > which user serial/network/disk device drivers. However, if it's > important for them to have things working the way they've expect to in > the past, they should either replace their desktop machines with fast > laptops or submit code to fix the problems with the existing code-base > that doesn't fit into the new 'swappable' system." > > Needless to say, this attitude won't buy me any friends. I have always said that devfs is an option and I think it should be the default option, because 98% of people don't change the permissions on devices, but I would be happy with it just being an easily available Non default option. I think that 90% of the remaining people could be satisfied with an rc.devs to change permissions of devices that are in some way special. that leaves 10% of 2% (0.2%) of maniacs who have to run /dev on their root partition using ufs. They of course don't see their new devices and slices show up as needed, and they don't automatically have the right number of ptys, and when they add a pc-card and run the lkm, they also have to make all the devices and they have old crap floating around in /dev for devices they long since threw away etc. etc. etc. but then that's how it is now so they should be happy. of course they also can't use the new volume manager or the bsd streams layers either because those REQUIRE a dynamic device interface, but they didn't have those things before either, so they should still be happy. personally I think that If it's insisted that I add persistance before it becomes generally available then it'll never happen. I need it to be in use with a wider audience or it'll never getthe bugs shaken out of it enough for me to go much further with it.. BTW I just discovered a bug with it that I am trying to figure out.. mount -t devfs devfs /mnt mount /mnt/wd0e /mnt2 umount /mnt2 [process hangs] I know what it is but it's a really tricky problem that I HOPED would not happen because it's a bitch to get around.. it's incompatibel in some ways to have one vnode for all instances of a device (e.g. /dev/tty and /chroot/dev/tty) AND solve this problem.. because if they have the same vnode, Which mount point does it reference? and it must reference ONE of them, because mount hangs the super block off it and oh well, I guess I can solve it with another level of indirection.. you can solve ANYTHING with enough levels of indirection... julian