Re: Devices.
least that much testing. It may be that devfs takes two or three releases to advance from one level to the next. > 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'd like to avoid hardwired policy. The devfs instances I've worked with have a reasonably sane default set of rules, and a way to apply additional rules for specific situations. Making devfs a simple set of tools, and leave the complexity to the users of the tools (device drivers, admin defined rulesets) is the better way to go, IMHO. It should follow the "small tools that do one thing and do it well" philosophy. Maintaining the rules in kernel space means they can be applied during attach without jumping out of the kernel or requiring a watcher daemon to notice new devices and make system calls to apply the rules. There will need to be userland tools to manage the rules in the kernel, of course. Those tools, which may include some policy daemons, update the mechanism (rules) in the kernel. > > [...] 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. Of course not. It would be to: - To provide an API for device drivers to manage their own device nodes, - To allow for auto-discovery/creation of device nodes, - To allow complex devices to own their own complexity, - To provide a sensible default policy for common cases, - With the ability to override for specific use cases, - To (optionally) provide a MAC security policy in /dev, - And reduce the clutter. jf -- John Franklin frank...@elfie.org signature.asc Description: PGP signature
Re: partial failures in write(2) (and read(2))
On Feb 10, 2021, at 18:28, Thor Lancelot Simon wrote: > > On Fri, Feb 05, 2021 at 08:10:06PM -0500, Mouse wrote: >>> It is possible for write() calls to fail partway through, after >>> already having written some data. >> >> It is. As you note later, it's also possible for read(). >> >> The rightest thing to do, it seems to me, would be to return the error >> indication along with how much was successfully written (or read). But >> that, of course, requires a completely new API, which I gather is more >> intrusive than you want to get into here. > > I think it could be done with a signal in combination with the existing > API. From the application’s perspective of calling write() in libc, when there is such an error the libc function could return a short response and set errno. That doesn’t work so much for the kernel’s system call. I suppose libc could set a default handler for the new signal, and do some extra work to set errno. Apps that need more control can override the signal hander. jf -- John Franklin frank...@elfie.org
Re: Issues with intelfb(4) and USB keyboards
On Sat, Dec 19, 2020 at 3:44 PM, RVP wrote: On Sat, 19 Dec 2020, Brian Buhrow wrote: hello. Thanks for the quick explanation. It still doesn't work, but the errors are different. Any ideas what to try next? How does one set the dot clock? Suggestions: 1. Try the latest -HEAD build. It may have fixes. 2. Try `genfb/wsfb'--the generic framebuffer and the X driver which runs on top of `genfb'. Disable i915drmkms using the userconf facility: https://mail-index.netbsd.org/tech-x11/2020/12/10/msg002183.html Another suggestion, check the Xorg.0.log for clues. There should be log entries in there about reported EDID information, what display outputs the driver can see, and maybe something about which one it's choosing. jf -- John Franklin frank...@elfie.org
Re: kernel frameworks for jumbo frame
On Mar 10, 2019, at 15:33, Gert Doering wrote: > > Hi, > > On Sun, Mar 10, 2019 at 12:14:54PM -0700, Brian Buhrow wrote: >> hello. I'm not saying anything that anyone here doesn't already know, >> but I'll add that Linux seems to have taken the position that all ethernet >> interfaces should be called eth0, eth1, etc. > > This argument surprises me a bit, as Linux has moved *away* from doing > exactly this a few years ago... Depending on who you ask, this was either poorly received by the community or “has mixed reviews.” I’ve yet to meet someone who thought it was the best thing ever. That said, when I worked more with NetBSD I had little difficulties working with igb0, and the like. Perhaps because NetBSD feels like I’m working closer to the hardware than Linux, it felt more natural to specify the driver as part of the network device name. Or maybe because I was using NetBSD before I was using Linux, it was just how things worked. When I did start using Linux circa 2000, the “a NIC is a NIC” naming abstraction made a lot of sense. (Yes, I know “a NIC is a NIC” is too facile when you get to the nitty gritty details. There are different features and status exposed via different drivers, depending on the capabilities of the chip — checksum offloading, max frame size, etc — all handled via the driver settings and ioctl. But, for the basics and simply getting the name of the device, the abstraction works well.) > Personally, I'm a bit torn on what is "the best" thing. > > On a system that only has one ethernet card, it's highly annoying > that I have to figure out if this is a "em0" or "igb0" - or an > "eno1" vs. "enp0s25" (both "onboard ethernet 0", but BIOS tables > leading udev to believing the second one isn't). So "eth0, always" > would be very convenient. Or possibly "eth0" for "wired ethernet" > and "wifi0" for wireless - as that's a common scenario. > > For a system with multiple ethernet cards (server with frontend/backend > networks, or firewals, or routers) naming *stability* is a must - having > "em0" and "em1" swap their numbers at upgrading is as disruptive as > "eth0 and eth1 get swapped because one card had to be changed and the > other driver loads first". So here, something based on bus numbering > might be best - stability trumping convenience... This is something I thought was solved *years ago* in the Linux world, and I don’t understand why udev/systemd had to break it. The first time a system boots, the kernel assigned network cards in the order discovered eth0, eth1…ethX, and recorded the device ID to a MAC address mapping in a udev rule. On subsequent boots, the kernel through the udev rules would retain the same device IDs, even if the kernel discovered them in a different order. If a card is replaced, then the new one would get the next ID by default. If an admin wants a certain order, the rules can be changed. In my experience, it worked fine for the simple case of desktops and laptops with one NIC, it provided reasonable defaults and stability in multi-NIC servers, and allowed for arbitrarily complex situations. It’s only in the infrequent case of a replacement NIC that would force an admin to find and update the udev rules (he’s in there already updating the hardware!), which IMHO, falls under Works As Intended. Splitting eth0 vs wifi0 makes sense to me, as the inherent nature of the devices are fundamentally different. jf -- John Franklin frank...@elfie.org smime.p7s Description: S/MIME cryptographic signature
