Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Oct 1999 17:26:25 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        phk@critter.freebsd.dk (Poul-Henning Kamp)
Cc:        tlambert@primenet.com, freebsd-arch@freebsd.org
Subject:   Re: The eventual fate of BLOCK devices.
Message-ID:  <199910181726.KAA03157@usr07.primenet.com>
In-Reply-To: <6153.940266332@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:05:32 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910181726.KAA03157>