From owner-freebsd-hackers Sat Jul 15 3:10:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 5BEB937BC28 for ; Sat, 15 Jul 2000 03:10:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from bissau-16.budapest.interware.hu ([195.70.53.144] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13DOu0-0001C6-00; Sat, 15 Jul 2000 12:10:33 +0200 Message-ID: <39703884.15FB7483@elischer.org> Date: Sat, 15 Jul 2000 03:10:12 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Coleman Kane , hackers@FreeBSD.ORG Subject: Re: DEVFS References: <4007.963643480@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <20000715013940.A51575@cokane.yi.org>, Coleman Kane writes: > > >Who is currently working on the DEVFS? I emailed the last person > >to commit to the HOWTO and got no response. I'd like to look into > >finisheing this, and may start hacking if no one tells me otherwise... Well, it was almost fully working before soem core members decided to delete part of the support code for no apparent reason. However there are some new design criteria that need to be considered that the old devfs didn't consider. (that is why one makes a prototype, so that one learns what is important). For example, it turns out that one of the important items a devfs needs to take into account is the ability for an operator to populate chroot/jail regions with a subset of devices. Puting a mountpoint for a devfs on each jail (there could be thousands) is not a winning solution. This suggests that the base filesystem needs to be involved in some way. Also the probing of new devices and disk partitions as they are loaded and created can be problematic. (that is what the deleted code did). I am now of the opinion that there needs to be a kernel devd which is responsible for probing out new partition hierarchies (with it's own context), and other actions within the devfs. it is even possible, given Poul-henning's device nodes within the kernel that much of the functionality that is looked for with devfs can be achieved via other means. Certainly the whole concept is up for discussion. > > bp@ has a non-working prototype, (as has julian@). > > None of them fixes the root-mount kludges. actually the code you and SOS delted DID solve that.... > > None of them implement cloning devices. no, though have you tried looking at ptys under devfs.. as you use them, more are created.. (a bit of a hack but kinda cute). > > If you (or a group of people) seriously want to work on DEVFS, send > me an email and I will coordinate and try to make sure we get this > done *right* so that we cover all the issues we need to cover with > devfs (root-mount, jail, cloning etc etc) Of better still email me too. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message