At Sat, 29 May 2021 16:17:13 -0700, John Nemeth <jnem...@cue.bc.ca> wrote: Subject: Re: Devices. > > On May 29, 22:52, David Holland wrote: > } On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote: > } > } > > For disks, which for historical reasons live in both cdevsw and > } > > bdevsw, both entries would point at the same disk_dev. > } > > } > I would suggest getting rid of the bdev/cdev distinction. It is, as > } > you say, a historical artifact, and IMO it is not serving anyone at > } > this point. > } > } It is deeply baked into the system call API and into POSIX, so it's > } not going anywhere. It's been proposed that we should stop having > } block devices, which would have the same net effect; I have no strong > } opinion on that and it doesn't need to be part of this set of changes. > > I was thinking the same thing about getting rid of block > devices. The only place they should ever be used is an argument > to mount(2) and mount(2) can be adjusted to use a block device > underneath when it is handed a character device. FreeBSD got rid > of block devices a long time ago. Doing that as a first step is > likely to simplify things to make other things easier.
I'm uncomfortable with what seems to me to be a rather arbitrary decision to remove block devices from NetBSD. My understanding w.r.t. the rationale FreeBSD used in deciding to remove the block devices was that FreeBSD never really buffered/cached by device in the first place. Also, according to PHK in his 2002 BSDCan paper about FreeBSD's /dev, "In FreeBSD block devices were not even implemented in a fashion which would be of any use, since any write errors would never be reported to the writing process."[*] [*] https://www.usenix.org/legacy/events/bsdcon02/full_papers/kamp/kamp_html/index.html If I'm not mistaken that's all different in NetBSD though (except maybe for the error handling issue), or am I mistaken??? Of course on Linux the went the other way and there are no raw devices, and clearly that's turned out to be a bad idea, especially for the needs of some tools such as 'dd' and the underlying drivers which all had to double down and add new non-standard controls just to re-implement "raw" access. > We should really get with the times and create a devfs. I dunno. I think it's a good idea for some classes of devices, but I'm not so sure it has to be a one-size-fits-all singular solution. -- Greg A. Woods <gwo...@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca> Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
pgp4sxzsRR_r8.pgp
Description: OpenPGP Digital Signature
