From owner-freebsd-arch Mon Oct 18 10:27:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D094714A2D for ; Mon, 18 Oct 1999 10:27:55 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25570 for ; Mon, 18 Oct 1999 19:27:55 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78735 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:27:53 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id EE09714A2D for ; Mon, 18 Oct 1999 10:26:49 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id KAA23845; Mon, 18 Oct 1999 10:26:34 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAALJaqGU; Mon Oct 18 10:26:31 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA03157; Mon, 18 Oct 1999 10:26:26 -0700 (MST) From: Terry Lambert Message-Id: <199910181726.KAA03157@usr07.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Oct 1999 17:26:25 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-arch@freebsd.org In-Reply-To: <6153.940266332@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:05:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Here's an argument I haven't heard before, and then a response to > >Julian: > > > > > >Question 1: How will I netboot my non-FreeBSD OS that > > requires block devices using an NFS mounted > > / containing that OS's /dev, if FreeBSD can > > not support block devices in its FS? > > No, it will not affect this. The open of a special node > happens on the client side, and stat(2) will return the > right thing. So you are saying that the mknod won't go away, just that the nodes will not have the expected behaviour in FreeBSD. I think that if the nodes are still possible, they ought not to be duncels; at least there should be a compatability mode where they are not. I think the cost is a single "if" test on the "b"-ness of a device && the ioctl() function pointer being non-NULL (ie. the LKM is loaded. I get uncomfortable when functionality is permanently removed; the removal of block devices, as opposed to their being made optional, feels too much like when we lost the ISODE and X.25 code for lack of rigor when the new networking APIs and model were turned on. I truly think that if such a big change is going to be made, that it's up to the person making the change to be rigorous in case we find a hole in our foot two or three months down the road. I think that so long as the block nodes will remain, that the single "if (x && y)" and ioctl() code, even as an LKM, is a small overhead for the people removing the code to bear, with the benefit that we don't really lose functionality, and that people who wish to "bloat" their kernel back up can do so in order to not lose block device functionality. I keep hearing that an ioctl() to reenable the functionality would be trivial, but it doesn't seem that trivial to me, considering the coherency issues, so I would definitely prefer that it be implemented by someone who feel that it _is_ trivial, rather than me (I'm certain that I'd blow the coherency issues out of all proportion, with a sidebar implementation, and I'm not positive that others wouldn't as well, but I know I would). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message