Re: Devices without power management support
On Fri, Aug 19, 2022 at 01:52:47AM +, Taylor R Campbell wrote:
> All that said: What is the failure mode you're seeing for ihidev that
> blocks suspend?
It fails to read HID descriptor. The ihidev device remains unfunctionnal
and breaks suspend.
I thought about this workaround:
--- sys/dev/i2c/ihidev.c.orig
+++ sys/dev/i2c/ihidev.c
@@ -161,8 +163,17 @@
sc->sc_tag = ia->ia_tag;
sc->sc_addr = ia->ia_addr;
mutex_init(>sc_lock, MUTEX_DEFAULT, IPL_NONE);
+ /*
+* We register null handlers so that a failed attachement
+* does not result in a device that breaks suspend.
+* The real handler are registered at the end of this
+* function on success.
+*/
+ if (!pmf_device_register(self, NULL, NULL))
+ aprint_error_dev(self, "couldn't establish power handler\n");
+
sc->sc_phandle = ia->ia_cookie;
if (ia->ia_cookietype != I2C_COOKIE_ACPI) {
aprint_error(": unsupported device tree type\n");
return;
--
Emmanuel Dreyfus
m...@netbsd.org
Re: Devices without power management support
p...@whooppee.com (Paul Goyette) writes: >Don't forget to deregister the device if the xxx_attach() later exits... I think the point was to not do this, so that a failed attach doesn't prevent the system from entering sleep mode. Here, calling pmf_register first on attachment is then required, but then you have to think on how to handle failures of pmf_register. You wouldn't want the device to fail attachment in that case, but rather accept that you cannot suspend in that situation. You also have to think about drivers that are left only partially configured after a failed attachment. That is already unsafe with drivers that only do a dummy pmf registration, but what about hardware that actually needs support routines ? Registering these for a partially configured driver may not work either. Unregister again and register dummy routines ? An easy solution would be to make attach actually fail, autoconf could then detached the driver immediately and it won't interfere with pmf. N.B. if autoconf API is changed, you could also integrate pmf into cfattach.
Re: Devices without power management support
> Date: Fri, 19 Aug 2022 01:22:39 + > From: Emmanuel Dreyfus > > I have patches to move the pmf_device_register() earlier in xxx_attach() > to workaround the problem in iwm(4) and ihidev(4) where I encounter the > problem, but perhaps the problem could be worked around globaly, by not > failing sleep mode if a driver did not call pmf_device_register()? I think we should just make the device suspend/resume functions be autoconf routines like match, attach, detach, and dispense with pmf_device_register altogether. FYI, moving pmf_device_register earlier can turn a working driver into a broken driver, because right now there's nothing that prevents suspend from happening before attach completes, and the suspend routine may assume that attach has completed. All that said: What is the failure mode you're seeing for ihidev that blocks suspend? (iwm(4) attach is flaky and needs to be rototilled, but I'd rather not touch that on HEAD while martin's wifi branch is in progress.)
Re: Devices without power management support
On Fri, 19 Aug 2022, Emmanuel Dreyfus wrote: Hello When a devices fails initialization, the xxx_attach() function may exit early, before calling pmf_device_register(). The consequence is that any attempt to put the system to sleep fail with a "Devices without power management support: ..." message. Weird things happens, and I experienced situation where some devices randomly or always fail initialization. This breaks sleeping mode. I have patches to move the pmf_device_register() earlier in xxx_attach() to workaround the problem in iwm(4) and ihidev(4) where I encounter the problem, but perhaps the problem could be worked around globaly, by not failing sleep mode if a driver did not call pmf_device_register()? Don't forget to deregister the device if the xxx_attach() later exits... Of course the lack of a registered suspend handler may miss the expectation of a system sleeping with reduced power, but on the other hand, being unable to sleep at all means even less power reduction. -- Emmanuel Dreyfus m...@netbsd.org !DSPAM:62fee614256621427699200! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Devices.
> A working devfs that can be used in all places where device nodes > might be needed would mean that the device vnode apparatus in ffs and > every other fs could be removed, yes, ...only if you don't mind breaking compatability. I don't know to what extent compatability is necessary, but I think it's something that needs to be at least thought about. Device nodes in filesystems need to not break ffs (inter alia), or you can't mount old filesystems and poke around, but to what extent do they need to _work_? I'm not sure what I think in that regard. I actually think much of my resistance to a devfs is that it makes it significantly more difficult to have device nodes outside /dev. I've used a Unix-ish emulation layer (an early prerelease of Eunice) whose /dev was heavy magic, and it was always a bad fit; when I started using the real thing it made much more sense. Confining device nodes to /dev strikes me as an excellent example of preventing stupid things and thereby preventing clever things. (Symlinks help, some, but without set-id symlinks they can't really make up the difference. And as far as I know nobody, not even I, has implemented set-id symlinks yet.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Devices.
On Tue, Jun 01, 2021 at 10:08:55AM -0700, Brian Buhrow wrote: > hello David. What I don't see in your proposal is a way of > implementing a dynamic device filesystem. As I already posted about once, that's irrelevant to what I'm proposing. A working devfs that can be used in all places where device nodes might be needed would mean that the device vnode apparatus in ffs and every other fs could be removed, yes, but that does not _solve_ the problem that puts it there, it only centralizes it. Meanwhile it addresses none of the other issues. Also, devfs as popularly envisioned remains a bad idea. As I said before, it's an automounter, not a file system, and automounters are accursed. If you (or anyone else) really wants it to happen, I recommend sorting out _in detail_ how to configure it and where (and how) to store the persistent state it needs to remain compatible with expectations. For example, suppose there are two (different) chroots as well as the "real" /dev and someone inserts a USB microphone, with the intent that one of the chroots (which they're using as a sandbox for a popular videoconferencing app) can use it and the other (which is running code that's potentially overtly hostile) cannot. How do you decide the user/group and mode for the new device node in each of the three instances of /dev? In what language do you write the policy that describes what's supposed to happen? And where does the decision logic execute? Where is the policy stored? How do you get it to reload when needed? None of this is trivial. Also decide for certain whether the objects your devfs automounter adds to the namespace are in fact ordinary device special files with hardcoded major/minor numbers (this is a lot simpler, but defeats much of the point) or should be something more flexible, like dynamically generated vnodes that connect directly to device drivers. Unlike most people talking about it (here and elsewhere) I have actually implemented this (in a research system) and my conclusion from that experience was that it was a mistake. I don't propose to waste my time doing it again. > The way we handle ZFS is just goofy As far as I know this is largely or entirely the fault of the ZFS developers for doing their own thing instead of sticking to the established/conventional abstractions for devices and file systems. -- David A. Holland dholl...@netbsd.org
Re: Devices.
wo...@planix.ca ("Greg A. Woods") writes:
>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???
The same arguments are pretty much valid for NetBSD too. But to a large
degree that's more an argument to make such things work.
If you remove block devices, you still want to distinguish between
buffered access (can be done in arbitrary sizes, read-modify-write
as necessary) and raw access (direct hardware I/O with its limitations).
You can do that with e.g. flags to open(). Or you can require that
each program handles this privately. Neither will be compatible
with the current behaviour.
re: Devices.
Brian Buhrow writes: > hello David. What I don't see in your proposal is a way of > implementing a dynamic device > filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that > I'm aware of that > use static special files in their filesystems to point to devices. If your > proposal was i don't believe this is a correct claim. linux with udev is, at any reasonably high level, the same as netbsd with devpubd. .mrg.
Re: Devices.
At Tue, 1 Jun 2021 14:00:50 -0400 (EDT), Mouse wrote: Subject: Re: Devices. > > Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the > chroot to have as minimal a set of devices as still allows it to do its > job, and in particular I do not want it to ever dynamically acquire new > devices, nor do I want it to have /dev entries for devices not > necessary for its task. I not infrequently want unusual ownerships or > permissions on its /dev, too. Indeed. Very important! > I also want to be able to have device nodes places other than /dev, and > that desire is at least mostly orthogonal to chroot. I'm less convinced of this part though This ability has brought more complexity (e.g. mount options to disable devices per filesystem) than I've ever seen pay off in benefit. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp8ynnPwmB1n.pgp Description: OpenPGP Digital Signature
Re: Devices.
At Sat, 29 May 2021 16:17:13 -0700, John Nemeth 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgp4sxzsRR_r8.pgp Description: OpenPGP Digital Signature
Re: Devices.
On Sun 30 May 2021 at 19:30:04 -0400, John Franklin wrote: > Consider, a USB device is inserted... > that has a mass storage block device... > encrypted with CGD... > hosting a partition map... > with an LVM PV in one of the partitions... > that contains three LVs. > > How many device nodes are created here? If I were to design a devfs for this, the resulting device nodes would become a directory tree, for the given case something like sd0-+-cgd0-+-cgd0a-+-pv0-+-lv0 |-lv1 \-lv2 "Somehow" these nodes would be device nodes and directories at the same time. That would be much nicer than having two nodes (with slightly different names), one for the device node and one for the directory. I don't think I've seen a devfs like that; there is a hierarchy in the linux /sys/devices but it is determined by physical hardware attachment. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Devices.
> When you want a device tree in a chroot, you just mount the device > filesystem on that chroot. Uh, maybe _you_ do. _I_ don't. For most of my chroots, I want the chroot to have as minimal a set of devices as still allows it to do its job, and in particular I do not want it to ever dynamically acquire new devices, nor do I want it to have /dev entries for devices not necessary for its task. I not infrequently want unusual ownerships or permissions on its /dev, too. I also want to be able to have device nodes places other than /dev, and that desire is at least mostly orthogonal to chroot. A devfs that could be configured that way, well, maybe. Most of the ones I've seen can't, but I haven't been staying au courant with them. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Devices.
hello David. What I don't see in your proposal is a way of implementing a dynamic device filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that I'm aware of that use static special files in their filesystems to point to devices. If your proposal was extended with the idea that we have a device filesystem, then wouldn't we only need one implementation of a filesystem that knows anything about devices? When you want a device tree in a chroot, you just mount the device filesystem on that chroot. That filesystem would need a utility that converts a configuration file or database into static permissions and ownership, but that could be done on a per-instance basis, i.e. have a configuration that describes /dev at the root of the system, and other /dev's that describe chrooted dev environments, or dev's in application directories. The only case that doesn't cover, that I'm aware of, is what to do about sockets and fifos, which are commonly scattered all over filesystem trees. In any case, with the advent of gpt named partitions, zfs volumes, USB pluggable devices and other dynamic device environments, not having a dynamic device filesystem is becoming a real detriment. The way we handle ZFS is just goofy and fraught with bugs in dynamic situations.I'd like to see a more integrated approach to this problem. -thanks -Brian
Re: Devices.
On Sat, May 29, 2021 at 08:43:00PM -0400, Mouse wrote: > > We should really get with the times and create a devfs. I know that > > there are people that disagree with this (likely including you), but > > the archaic device node system causes a lot of headaches and it's > > time that we joined the 21st century. > > I am not someone who thinks that we, for any value of 'we", should go > with the new simply because it's new. I strongly agree with this. Too much modern "new" stuff is a downgrade from the previous version, or adds complexity without solving a real problem, or tempts you with something shiny while shackling you to a particular vendor or solution. The days of "new and improved" seem to be all but over. I don't think devfs falls into this category. > I'm curious what headaches you think devfs would fix. (I know what > headaches *I* think it would fix. I'm wondering which ones *you* think > are worth bringing it in for.) Even though I didn't start this thread, I'd like to chime in here. Hardware isn't static, and hasn't been for a long time. Hot-pluggable devices are common on all grades of machine, from embedded systems to laptops/desktops to servers to large VM hosts. We add physical storage in the form of USB drives, eSATA disks, iSCSI and FC LUNs. We add logical storage in the form of crypto block devices, LVM LVs, and partition maps. Beyond mass storage, Bluetooth and USB devices can be network adapters, cameras, audio devices (both in and out), and (thanks to USB-C/TB3) even display devices. The device drivers intrinsically know where in the /dev tree they belong, and can instantiate themselves during attach. It shouldn't require running a userland script or daemon to create new devices. Managing hardware and exposing it to the rest of the system is a job for the kernel. System hardware is dynamic and /dev should be dynamic, too. Modern hardware is complicated. For some, like a USB disk, a single physical device may create multiple nodes, one for the raw USB functions under /dev/usb/, and one for the block device itself. Going back to David's original question of defining classes of devices, devices that are multi-classed and need separate device nodes for each class will need to call functions for all applicable classes. The device driver has full knowledge of the device, let it own the complexity. More complex storage (ZFS, LVM) may create canonical nodes and populate a /dev/mapper subdirectory with symlinks of more human friendly names. For matroska devices, automatic population of /dev is more sane if the device drivers do it themselves: Consider, a USB device is inserted... that has a mass storage block device... encrypted with CGD... hosting a partition map... with an LVM PV in one of the partitions... that contains three LVs. How many device nodes are created here? A devfs makes it easier to migrate from node major,minor numbers to device names/IDs, because the device drivers know who they are and create their own devfs device nodes with appropriate names. A devfs may not bother with names and just map device nodes to device structures. Finally, reducing the clutter. A default NetBSD install has nearly 900 device nodes, the majority of which point to nothing on a given system. > The major downside I've seen is that they also render difficult or > impossible a number of clever things that are rarely useful but > borderline essential when they are useful. Most of those things are As with FreeBSD, a devfs should be optional early on, something that is an enabled option in the kernel config, and maybe require an explicit entry in /etc/fstab to mount. Even after devfs goes mainstream, I'd expect mknod(2) to stick around. Specialized installs with limited memory and truly static devices (think: IoT) may want to stick with plain device nodes. > based on devices being "just" filesystem nodes, leading to things such > as the same device appearing more than once in the filesystem > (including places outside /dev), things such as chroot areas with > hand-crafted (and severely cut-down) /dev directories...some of the > devfs variants I've seen don't even support chmod/chown. Should /dev have a MAC or DAC security policy? That's a debate of it's own. Yes, MAC makes it harder to manage. Security = 1 / convenience. As for chroot environments, the kernel has an outside view and can craft a /dev specific for the chroot-jail, per a defined ruleset. > By the time you (re)implement all the filesystem operations that give > /dev much of its power, you're pretty much back where you started, only > with a custom filesystem - with new and different bugs and far less > well tested code - on /dev. Experimental in 10, optional in 11, preferred in 12, default in 13. That's a rather optimistic schedule. It's a critical subsystem and deserves at least that much testing. It may be that devfs takes two or three releases to advance from one level to the next. >
Re: Devices.
>> You can run devpubd. When a wedge and thus the dk* unit attaches, >> it runs the 01-makedev hook that creates the device node in /dev. > That's not a "mode". It's a clunky userland daemon that tries to > make up for the fact that we don't have a devfs. Your wording is heavily biased. To bias in the other direction: I take it you'd rather have that policy hardwired into the kernel, where it can't be changed without kernel-hacking expertise and a reboot, and any bug takes down the whole system, rather than in userland, where it can be changed anytime, and bugs just cause that one piece to break? I would rather have the userland version. "Mechanism, not policy." /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Devices.
On May 30, 14:24, Michael van Elst wrote:
} mueller6...@twc.com ("Thomas Mueller") writes:
}
} > Where do I find the "enough dk* nodes" mode? Would it be in
} > the kernel config? I never saw it.
}
} You can run devpubd. When a wedge and thus the dk* unit attaches, it
} runs the 01-makedev hook that creates the device node in /dev.
That's not a "mode". It's a clunky userland daemon that tries
to make up for the fact that we don't have a devfs.
}-- End of excerpt from Michael van Elst
Re: Devices.
mueller6...@twc.com ("Thomas Mueller") writes:
>Where do I find the "enough dk* nodes" mode? Would it be in the kernel
>config? I never saw it.
You can run devpubd. When a wedge and thus the dk* unit attaches, it
runs the 01-makedev hook that creates the device node in /dev.
Re: Devices.
from Michael van Elst:
> mueller6...@twc.com ("Thomas Mueller") writes:
> >It's a nuisance not to be able to recognize all partitions on a
> >GPT-partitioned drive because not enough dk* nodes have been configured.
> >FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
> >between GPT
partitions and MBR-based partitions: better than Linux in that regard.
> We don't even use MBR based partitions, that's just compatibility for
> firwmare.
> We also have a "enough dk* nodes" mode but that's disabled by default.
> I personally think that all the "we don't do things like system X" claims
> are a nuisance.
Where do I find the "enough dk* nodes" mode? Would it be in the kernel config?
I never saw it.
Tom
Re: Devices.
mueller6...@twc.com ("Thomas Mueller") writes:
>It's a nuisance not to be able to recognize all partitions on a
>GPT-partitioned drive because not enough dk* nodes have been configured.
>FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and
>between GPT partitions and MBR-based partitions: better than Linux in that
>regard.
We don't even use MBR based partitions, that's just compatibility for firwmare.
We also have a "enough dk* nodes" mode but that's disabled by default.
I personally think that all the "we don't do things like system X" claims
are a nuisance.
Re: Devices.
from John Nemeth: > 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. > } > > A third question: how does this affect interfaces? } > > } > As in, network interfaces? Good question. I think they should be > } > device nodes in the filesystem *somehow*. } > } That's probably true, but they currently aren't and the plumbing above > } them is unrelated to the VFS device plumbing, so for the time being > } it's a separate issue. } > } Disentangling the current situation with device special files on > } filesystems will make it easier to manifest interfaces on disk if we > } ultimately want that. > We should really get with the times and create a devfs. I > know that there are people that disagree with this (likely including > you), but the archaic device node system causes a lot of headaches > and it's time that we joined the 21st century. Anything done with > devices should be done with idea of a devfs in mind. Yes, devfs > like things have caused a lot of problems on other operating systems, > but I think we have enough brain power and enough real world examples > to be able to not repeat the mistakes of the past. > }-- End of excerpt from David Holland I strongly agree on creating a devfs! I remember the days of static device nodes in Linux and FreeBSD. FreeBSD switched to devfs with v5 and 6; static device nodes became no longer an option. It is nice to be able to run "ls /dev/da*" and see what USB sticks and hard drives are connected. I believe Linux can still use static device nodes, but users generally prefer dynamic device nodes. It's a nuisance not to be able to recognize all partitions on a GPT-partitioned drive because not enough dk* nodes have been configured. FreeBSD even distinguishes between USB or SCSI disks and SATA disks, and between GPT partitions and MBR-based partitions: better than Linux in that regard. OpenBSD still uses static device nodes and looks backward compared to NetBSD and FreeBSD. Tom
Re: Devices.
dholland-t...@netbsd.org (David Holland) writes: >This was all based on the experience of adding discard and adding the >dispatching for it as a first-class [bc]devsw op rather than an ioctl: >it was a pain because it ultimately required touching _every_ driver, >not just the ones that needed to support it, but it was far less of a >mess than plumbing it as an ioctl would have been. And it was a questionable decision as you need the discard operations to queue with other I/O operations.
Re: Devices.
> We should really get with the times and create a devfs. I know that > there are people that disagree with this (likely including you), but > the archaic device node system causes a lot of headaches and it's > time that we joined the 21st century. I am not someone who thinks that we, for any value of 'we", should go with the new simply because it's new. I've seen various flavours of devfs. They have good aspects. They also have bad aspects. I'm curious what headaches you think devfs would fix. (I know what headaches *I* think it would fix. I'm wondering which ones *you* think are worth bringing it in for.) The major downside I've seen is that they also render difficult or impossible a number of clever things that are rarely useful but borderline essential when they are useful. Most of those things are based on devices being "just" filesystem nodes, leading to things such as the same device appearing more than once in the filesystem (including places outside /dev), things such as chroot areas with hand-crafted (and severely cut-down) /dev directories...some of the devfs variants I've seen don't even support chmod/chown. By the time you (re)implement all the filesystem operations that give /dev much of its power, you're pretty much back where you started, only with a custom filesystem - with new and different bugs and far less well tested code - on /dev. devfs is a great thing to experiment with. NetBSD is - well, was - a good platform for that. Perhaps there's a devfs design somewhere that's solved enough of the issues that it's worth making available. But I really don't think doing away with conventional device nodes is sane yet. Most of the benefits of devfs can be achieved with some kind of userland interface to the autoconf tree and some userland daemons - mechanism, not policy. All the devfses I've seen have, in my opinion, way too much policy wired into them. > [...] I think we have enough brain power and enough real world > examples to be able to not repeat the mistakes of the past. Not if we do it to "join[] the 21st century". That's a very wrong reason to do...well, almost anything technical. IMO. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Devices.
On Sat, May 29, 2021 at 04:17:13PM -0700, John Nemeth wrote: > We should really get with the times and create a devfs. I > know that there are people that disagree with this (likely including > you), but the archaic device node system causes a lot of headaches > and it's time that we joined the 21st century. Anything done with > devices should be done with idea of a devfs in mind. Yes, devfs > like things have caused a lot of problems on other operating systems, > but I think we have enough brain power and enough real world examples > to be able to not repeat the mistakes of the past. The problem with the devfs everyone wants is that it's an automounter, not a file system, which means that (a) everybody who tries to implement it as a file system discovers that the abstractions don't match up and ends up in varying degrees of trouble as a result, and (b) automounters seem to be inherently awful and devfs implementations thus are too. The stuff I'm proposing doesn't affect those issues, and is likely to make any implementation easier/simpler: it reduces the amount of work a fs with device special files on it needs to do, and it also provides the means to look up and "start" any given device or device instance as its own interface disentangled from the filesystem code. IMO the only significant problem that devfs solves is storing magic numbers (device major numbers) on disk, and I think that's readily (and better) solved by storing driver names instead of major numbers. Otherwise it's mostly a matter of not cluttering /dev with entries for hardware you don't have (nice but not a big deal) and not needing to run MAKEDEV in various circumstances (definitely useful, but not exactly critical)... all of which would be all very well if a clean implementation existed, but given that this does not seem to be the case it doesn't seem to me to be worthwhile. -- David A. Holland dholl...@netbsd.org
Re: Devices.
On Sun, May 30, 2021 at 12:00:16AM +0200, Johnny Billquist wrote: > On 2021-05-29 22:26, David Holland wrote: > > There are a number of infelicities in the way we currently handle the > > I/O plumbing for devices in the kernel. These include: > > [...] > > Just looking/thinking about the ioctl part - you say abolish it inside the > kernel. So does that mean that we keep the ioctl() interface for user > programs, but we'd create a system function that will translate ioctl() > calls from user programs to different function calls based on class and > function. Yes, that's the idea. Getting rid of it at the system call interface is a much harder problem (between compat, binary emulation, standards, masses of existing 3rd-party code that calls ioctl explicitly, etc.) and probably not worth biting off at all, let alone right now. (Hopefully this also addresses Paul's email.) This was all based on the experience of adding discard and adding the dispatching for it as a first-class [bc]devsw op rather than an ioctl: it was a pain because it ultimately required touching _every_ driver, not just the ones that needed to support it, but it was far less of a mess than plumbing it as an ioctl would have been. > Which means any time anyone wants to add some new kind of function to a > device, you'd have to adjust the ioctl() system call, the class, all > devices of that class, and of course your specific driver which you want to > do something with the hardware. That is correct; but normally when you do that (like with discard) you want it to exist on every device of that class, even if to begin with most of the implementations are "return ENOSYS". It is unlikely that ioctl can actually be made to go away entirely within the kernel or even the vnode side of the kernel (the networking code is also full of ioctls that this set of plumbing changes would not affect at all) so there'd probably still be a place to stick really ad hoc things. But mostly it's better to avoid those, especially because they gradually accrete into standard interfaces. :-| Note that even if it does become possible to kill off ioctl at the driver level it's not going to happen anytime soon, and that there will also likely need to be some kind of "misc" driver class as well. I would expect the process of moving in this direction to begin by carving off obvious device classes (e.g. disks, audio) and then migrating their ioctls; at some point we'll get to a stage where the stuff that's left is all atypical and it becomes a waste of time to try to make up a framework that fits it all. ... something I should have mentioned in the original mail: centralizing ioctl dispatch also allows having a single copy of any processing code for the arguments, which isn't a big deal for ordinary ioctls but should definitely help with robustness as soon as there are pointers involved or compat32 issues. -- David A. Holland dholl...@netbsd.org
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. } > > A third question: how does this affect interfaces? } > } > As in, network interfaces? Good question. I think they should be } > device nodes in the filesystem *somehow*. } } That's probably true, but they currently aren't and the plumbing above } them is unrelated to the VFS device plumbing, so for the time being } it's a separate issue. } } Disentangling the current situation with device special files on } filesystems will make it easier to manifest interfaces on disk if we } ultimately want that. We should really get with the times and create a devfs. I know that there are people that disagree with this (likely including you), but the archaic device node system causes a lot of headaches and it's time that we joined the 21st century. Anything done with devices should be done with idea of a devfs in mind. Yes, devfs like things have caused a lot of problems on other operating systems, but I think we have enough brain power and enough real world examples to be able to not repeat the mistakes of the past. }-- End of excerpt from David Holland
Re: Devices.
On Sat, May 29, 2021 at 05:41:38PM -0400, Mouse wrote: > There is, however, one thing I think is missing in your rework > proposal. I see nowhere to fit in a one-off driver for idiosyncratic > hardware - or as a pseudo-device interface to idiosyncratic kernel > code. I've personally done enough instances of each that I would find > it close to crippling if support for them were to be lost. It's unlikely to be possible to avoid having a device class called "miscellaneous" that such things could be stuffed into, because, as you note, they exist. > > 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. > > (2) Abolish ioctl inside the kernel, or at least within the device > > tree. > > This would, I think be possibly the hardest part of dealing with > idiosyncratic drivers such as I sketched above. Some of the drivers > I've done use ioctls, some use I/O on minor sub-numbers (eg, the low > three bits of the minor number select a functional interface whereas > the rest of the bits are the "true" minor number), but most of them > need something of the sort. Getting rid of it altogether is likely too optimistic for reality. See next email (upcoming). > > A third question: how does this affect interfaces? > > As in, network interfaces? Good question. I think they should be > device nodes in the filesystem *somehow*. That's probably true, but they currently aren't and the plumbing above them is unrelated to the VFS device plumbing, so for the time being it's a separate issue. Disentangling the current situation with device special files on filesystems will make it easier to manifest interfaces on disk if we ultimately want that. -- David A. Holland dholl...@netbsd.org
Re: Devices.
On 2021-05-29 22:26, David Holland wrote: There are a number of infelicities in the way we currently handle the I/O plumbing for devices in the kernel. These include: [...] Just looking/thinking about the ioctl part - you say abolish it inside the kernel. So does that mean that we keep the ioctl() interface for user programs, but we'd create a system function that will translate ioctl() calls from user programs to different function calls based on class and function. Which means any time anyone wants to add some new kind of function to a device, you'd have to adjust the ioctl() system call, the class, all devices of that class, and of course your specific driver which you want to do something with the hardware. Or did I misunderstand something here? I'm not trying to shoot anything down at this time. Just trying to understand the implications of the suggestion. I sortof like the idea of getting some generalization, which classes would bring. But the problem with ioctl causing duplication and all kind of efforts is at the same time also a strength in that you can add something new to a device without having to care at all about all other devices and code. Since nothing else really tries to understand ioctls. Flexible, but more effort if you want coherent behavior. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Devices.
On Sat, 29 May 2021, David Holland wrote: Anyhow, I think this architecture addresses all the problems cited. The critical question is: what have I overlooked? There are probably some issues I've thought about but failed to remember to discuss above; there are also probably some issues I've not thought about or am completely unaware of. One thing that would concern me is compat... :) It's great if, for example, we can rip out ioctl() but if we have to maintain it to provide compatability that might increase the problem by an order of magnitude. Some sort of transition planning would need to exist in the overall plan, and well-communicated to users. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Devices.
> There are a number of infelicities in the way we currently handle the > I/O plumbing for devices in the kernel. These include: [...] Thank you. I don't agree with all of that (which I daresay astonishes nobody), but much of it sounds like a codification of some vague unease that's been floating around half-formed in the back of my mind for...well, gradually forming for almost as long as I've been using Unix variants, meaning something like 40 years at this point. There is, however, one thing I think is missing in your rework proposal. I see nowhere to fit in a one-off driver for idiosyncratic hardware - or as a pseudo-device interface to idiosyncratic kernel code. I've personally done enough instances of each that I would find it close to crippling if support for them were to be lost. > 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. > (2) Abolish ioctl inside the kernel, or at least within the device > tree. This would, I think be possibly the hardest part of dealing with idiosyncratic drivers such as I sketched above. Some of the drivers I've done use ioctls, some use I/O on minor sub-numbers (eg, the low three bits of the minor number select a functional interface whereas the rest of the bits are the "true" minor number), but most of them need something of the sort. > A third question: how does this affect interfaces? As in, network interfaces? Good question. I think they should be device nodes in the filesystem *somehow*. For example, at present there is no way to grant someone tcpdump access to le0 without granting tcpdump access to all interfaces, short of a custom setuid program, or something even more contrived such as bridge and a special-purpose tap instance. Seems to me this really should be doable with as little as chown (or chgrp) and chmod, much as it currently is for (say) ttys. I also believe Bluetooth should be just another AF rather than being its own weird mess tacked onto the side of the networking subsystem. I don't know if that's worth taking on, but, given the magnitude of this overhaul, it seems like a good opportunity to fix things like that, or the aforementioned legacy cdev/bdev split. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Devices not at mainbus?
On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus).
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 08:52:38AM -0700, Matt Thomas wrote: On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Through parents. I'm looking at trying to inherit maxphys down the device tree. Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus). Oof. That's the answer, then, I guess. -- Thor Lancelot Simont...@panix.com We cannot usually in social life pursue a single value or a single moral aim, untroubled by the need to compromise with others. - H.L.A. Hart
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 12:03:49PM -0400, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Through parents. I'm looking at trying to inherit maxphys down the device tree. Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus). Oof. That's the answer, then, I guess. Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? -- David A. Holland dholl...@netbsd.org
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. Thor
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Yes. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. ah, and then the question is where to manifest those. right... -- David A. Holland dholl...@netbsd.org
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote: On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. Actually, anything that has a MAXPHYS restriction in Xen attaches to hypervisor. So hypervisorbus could set the property ... -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
