Re: Per-descriptor state
On Sun, Apr 30, 2023 at 12:49:03AM -0400, Mouse wrote: > This is pushing towards making it per-descriptor state. At present, > the versions I have don't have anything but close-on-exec as true > per-descriptor state. A quick look at 9.1 and cvsweb.netbsd.org > (which, mirabilu visu, actually works for me, unlike www.netbsd.org and > mail-index.netbsd.org) sys/sys/filedesc.h makes me think that that's > true of them as well. Close-on-fork is apparently either coming or already here, not sure which, but it's also per-descriptor. The thing is, per-descriptor state is a mess and it shouldn't be allowed to proliferate. The reason: the descriptor is an array index. There's plenty of room to store stuff in the object it looks up (that is, struct file) but storing stuff on the key side of the array is a problem. For a couple bits you can mask them off from the pointer (though even that's abusive); more than that and suddenly you need to double the size of the fdtable so it contains an extra machine word for random state bits as well as the pointer to the struct file. Granted, it's not like this is going to make any machine (that can run Unix at all) tip over from KVA exhaustion, but it's untidy, messy, wasteful, and generally offensive to cleanliness. In general I think there is very little reason to have per-descriptor (rather than per-open) state and the only really valid use cases are those that pertain specifically to individual descriptor numbers, which in turn is pretty much limited to close behavior like close-on-exec. Granted, that's for files, where if you want two independent opens of the same file it's mostly not difficult to get them. For sockets that isn't a thing. But I kind of think it'd be preferable to make a way to clone a second independent struct file for the same socket than to start mucking with per-descriptor state. (Then there's also another issue, which is that in nearly all cases nonblocking I/O is a workaround for interface bugs, e.g. nonblocking accept or open of dialout modem devices, or for structural problems in software that also needs to use the same file handle, like your original problem with curses. In the long run it's probably better to kill off the reasons to want to use nonblocking I/O at all.) (also, "mirabile visu") -- David A. Holland dholl...@netbsd.org
Per-descriptor state
Back in late March, I wrote here (under the Subject: Re: flock(2):
locking against itself?) about a locking issue, which drifted into
discussing per-descriptor state versus per-open state (thank you
dholland for that phrasing!) versus backing-object state. In
particular, someone (I forget who) said that non-blocking really should
be per-operation rather than being state anywhere.
That's correct, but, thinking about it since then, that is not as easy
as one might wish, because there are quite a number of calls that can
be affected. (Offhand: {,p}{read,write}{,v}, connect, accept,
{send,recv}{,msg}, sendto, recvfrom. There are probably others, but
this is sixteen already - though I'm not sure p{read,write}{,v} need
the option; are there any seekable objects on which non-blocking is
significant?) Some of these, such as send*, already have a flags
argument that could grow a new bit to indicate nonblocking, but the
rest - more than half - would need to have an alternative version
created with a flags field, or some such. While hardly impossible,
this gets annoying, and indeed might be best addressed by (to use
read() as an example) making the real syscall backing read() always
take a flags argument, with the libc stub supplying a fixed value for
the flags when the flagless API is called.
This is pushing towards making it per-descriptor state. At present,
the versions I have don't have anything but close-on-exec as true
per-descriptor state. A quick look at 9.1 and cvsweb.netbsd.org
(which, mirabilu visu, actually works for me, unlike www.netbsd.org and
mail-index.netbsd.org) sys/sys/filedesc.h makes me think that that's
true of them as well.
For backward compatibility, I would be inclined to leave the existing
mechanisms in place, theoretically to be removed eventually. This also
means divorcing "non-blocking open" from "non-blocking I/O after open".
So: does anyone have any comments on the above analysis, or thoughts on
good, bad, or even just notable effects making it real per-descriptor
state might have?
/~\ 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: USB-related panic in 8.2_STABLE
> Date: Fri, 28 Apr 2023 11:32:44 +0200 > From: Edgar Fuß > > But we still don't know what led to the disconnect. Does the > ohci0: 1 scheduling overruns > give any clue? Suggests a hardware problem to me. According to the OHCI spec, this can happen if the driver has committed too much bandwidth, and the driver is supposed to reduce the bandwidth committed. However, it is supposed to be a transient problem that can be ignored a few times until it's happened for >=100 consecutive frames. I suspect this is relevant when there's a lot of isochronous activity (audio, video) and isn't supposed to happen otherwise. And the NetBSD ohci(4) driver doesn't do anything except print a message. So if that kind of activity wasn't happening, and if the device disconnected, it might indicate a hardware fault.
