Re: Interrupt handlers and mutex
>> (2) What happens when the interrupt handler cannot acquire the >> mutex? Will the LWP that holds it ever be able to run again? > That can't happen. The cpu will spin until the mutex is acquired. How can it ever be acquired? As long as the CPU sits spinning in the interrupt handler nothing but higher-priority interrupt handlers will get a chance to run, so the thread holding it can never finish its job and release it. Sure, if it's an MP system and the holding thread is on another CPU, I can see it, but I can't see how that can be guaranteed to be the case. There's clearly something I'm missing here. What is it? /~\ 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: The imperfect beauty of NetBSD
> time cat /usr/pkg/lib/python2.5/test/audiotest.au > /dev/audio > => > [ silence ] > real0m2.912s How large is that file? In particular, if it's not pretty close to 23296 (2.912*8000) bytes, something is wrong. > dmesg | egrep -i 'sound|audio' > => > [ nothing ] Assuming that dmesg by itself produces reasonable-looking output (ie, so long as dmesg itself isn't broken), this indicates your sound hardware isn't hooked up to the audio subsystem. I would expect the cat to /dev/audio to fail in that case - probably with some variety of "device not configured" - but I'm regularly surprised by things that work (or fail) in ways I did not expect. Perhaps post a pointer to full dmesg? Someone might be able to say something useful based on it. /~\ 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: Fastest dump device
> Wondering: would it make sense for savecore to run asynchronously, > rather than waiting for it to complete before continuing with the > rest of system startup? It risks something swapping over the data before savevcore gets it. However, if we can come up with a way to reliably notice if that happens, I think it would be a good option to have available, for cases where (a) the dump partition is _not_ used for swap or (b) the admin specifically chooses to run that risk for the sake of faster boot times (something I can certainly understand, especially since in more and more cases machines have so much core compared to their workload that actually paging anything out to swap is extremely rare). /~\ 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: Support for 4KB sectors size disk ?
> To support >512bytes/sector devices, we may have two choice: [...] What about <512? They exist; I have a floppy drive which I've been carefully hoarding because it has 256-octet blocks, the only device with <512-octet blocks I've ever seen (and it's SCSI, the only SCSI floppy drive I've ever seen, but that's irrelevant to this thread). Do we (FWVO "we") want to bother with such devices? /~\ 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: blocksizes
> This can easily happen if you copy the image between disks with > different block sizes. Now _there_ is a valid argument for doing everything in terms of bytes (as was discussed briefly upthread). /~\ 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: blocksizes
> fs_fsbtodb depends on the block size of the underlying medium. Does it? All you need to do is make a mental switch from thinking of fs_fsbtodb as "filesystem blocks to underlying device blocks" to thinking of it as "filesystem blocks to interchange blocks", where an "interchange block" is defined as 512 octets. Given how non-512-byte-sector devices have historically had their drivers pretend they're 512-byte-sector devices, this is what it actually is, after all - it's just that the mapping between interchange blocks and real device blocks has been handled by the device driver rather than by MI code. ...or...Am I Missing Something (tm)? /~\ 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: Cannot list a particular directory through NFS with UDP
> I have seen NFS fail (with the old 8K packets) on a network that was > badly terminated (back in the 10base2 days) because the back-to-back > packets self-collided while single packets with some spacing made it > fine. I recall I once had an NFS problem that exhibited itself as failures reading files of certain sizes. Turned out that the reader had problems receiving packets smaller than a certain size at the Ethernet level. UDP and NFS overhead meant that every packet was larger than that, but if the file size was right, the last data packet got fragmented and the last frag got lost thanks to this. As I recall, the sender padded to 60 octets but the receiver required 64 - but the exact values are rather fuzzy; this was decades ago. Mounting with rsize=1024 hid the problem, because then no NFS packet got hit with IP-layer fragmentation. A TCP mount would doubtless have worked just as well, if reliable TCP mounts had existed at the time (I don't think they did). /~\ 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: sysctl node names (Re: CVS commit: src/sys/uvm)
>> the current mixture of "enable" vs "enabled" seems ugly to me.
>> if my preference matters, i'd say "enable"/"disable".
> For me, "enabled" sounds more logical because such a flag refers to a
> state, not a process.
I'd say it's a question of whether you think of them as input to the
kernel, commands ("enable this"), or as output from the kernel,
reporting state ("this is enabled").
Of course, in most cases, they're actually both, so that doesn't help
much. But, as a native anglophone, it's what the difference between
"enable" and "enabled" here feels like to me.
/~\ 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: msync(2)
> I have a question reguarding mmap(2)ed files which are modified. Modified through the mmapped memory, I take it you mean? (They can also be modified through the filesystem interface, and most of the interesting questions hinge on having two different access paths to a single set of bytes.) > After reading the manual page of msync(2), I have the impression that > if invoked with the MS_SYNC flag, it should be safe enough not to > need a further fdatasync(2)/fsync_range(2) call afterwards? That's my own impression too - indeed, it's not clear to me that fdatasync has any bearing; it's not clear to me that an mmapped memory range is "data associated with" any file descriptor. It's at least as fd-specific as the fsync() you mention below. Is that how the current implementation works? I don't know. > And how about the metadata? Would sync(2) be the only true way to > ensure it's synchronized (considering fsync(2) seems fd-specific)? Good question. I have nothing useful to say there. > Also, I am auditing an application which seems to modify mmaped files > but which does not use msync(2) at all (and I can see that an older > fsync(2) call was used, but is now commented out). Should this be > considered a bug? In my opinion? No, unless access to the same files via filesystem methods needs to be coherent with the mmap()ped view. Maybe not even then, depending on things you haven't told us (eg, how restricted the target OS scope for the thing is - some things that are bugs if it's supposed to run on anything POSIX may not be fine if, say, anything except SunOS 4.1.1 on a SPARCstation-4 is out of scope). /~\ 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: msync(2)
>> [I]t's not clear to me that fdatasync has any bearing; it's not >> clear to me that an mmapped memory range is "data associated with" >> any file descriptor. > Indeed, and if I remember after mmap(2) a descriptor can be closed > before doing operations on the file, Well, before reading/writing the mapped memory; after closing the descriptor, there's no handle to perform other operations via. > [...mmapped data...] I've seen inconsistent data after a crash a few > times when using WAPBL, but not with softdep. That said, the > application could very well be using mmap unsafely... "Unsafely"? In the face of what threat model? It's hard to get data coherency guarantees out of mmap() in the face of "whole machine abruptly loses power" or equivalent threats; in general you don't even have write ordering preservation (you do in some special cases, such as with respect to writes that are wholly contained within the same block, where a "block" is the smaller of a disk sector and a VM page, but knowing that requires unwarranted chumminess with the implmentation). Strictly speaking, you don't even have that with disks, these days, with write-back caches and the like. But with disks, even if it's not guaranteed in theory, you generally have it in practice; with mmap(), this is not so. Graceful shutdowns, of course, should be fine. Even relatively controlled crashes - kernel panics for which dirty-page sync works - will usually be OK, though of course every panic is a can't-happen and thus can't really guarantee anything. /~\ 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: config(5) break down
>> [...] > See, this is the part that I don't understand. You're talking about > normalizing logic, which is fine, and making shared files first-class > entities, which is fine too though could get messy. > But then suddenly you jump into splitting up files.* into lots of > little tiny files and I don't see why or how that's connected to what > you're trying to do. Well, I don't know, because I didn't write it. But it seemed to me that the splitting-up was the whole point, with the rest being in aid of that, rather than, as seems to be your impression, that the semantics changes are the point, with the splitting-up a bizarre sideline. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
> Linux had a devfs and [dropped] it. Now it has udevd(8). Most > likely the penguins had a reason for this. Surely there are mailing list messages or something that outline that reason? (Not that I have any idea where they'd be, but don't we have at least a few people with feet in both camps?) > udevd(8) gives the user land control over device enumeration. Maybe > no bad idea. (Disclaimer: I don't like Linux.) I think it probably is no bad idea. I don't like Linux either, but I don't think it's so irremediably disastrous that there's nothing at all NetBSD could learn from it. > BTW: OSF/1 aka DEC-Unix aka Tru64-Unix did somthing like Linux + > udevd(8) over 10 years ago. Another reason to think that it's likely worth trying. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
> And now anyone who can jack around with the userspace daemon process > can cause you to mount a filesystem you didn't intend to mount. Anyone who can meddle with a root-run process can do a lot worse than that (to start with, mounting that filesystem directly). /~\ 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: (Semi-random) thoughts on device tree structure and devfs
> [...]. That makes devfs responsible to resolve confliction, which in > turn leads to some configuration thing, which I definitely want to > avoid. You need some kind of persistent state *somewhere*, to support chmod, chown, mv, rm, etc. Or are you proposing to break those? That idea strikes me as a pretty crippling regression. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>>> You need some kind of persistent state *somewhere*, to support >>> chmod, chown, mv, rm, etc. Or are you proposing to break those? >> My devfs doesn't do that complicate thing. > Wow, that sucks. Not being able to change permissions (and less > importantly, mv or rm the device files) would definitely be a > problem. That was my own reaction too, but, y'know what? What Uebayashi-san suggests is just fine as a research experiment, and, if it succeeds there, on the road to production use it can grow such things. NetBSD is still a decent framework for minor OS research experiments like that, and I think that's as it should be. Of course, anyone who proposes to put it into NetBSD's main released tree without support for such things should be shouted down. Vociferously. And thoroughly. Lack of chmod/chown/etc in /dev would be a total showstopper (for me, at the very least) for production use. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>>> Lack of chmod/chown/etc in /dev would be a total showstopper (for >>> me, at the very least) for production use. >> Could you tell me the senario how it sucks? > [...example, plain user access to serial line...] That's one of the scenarios I've run into, though for me it's at least as often been something other than a serial line - on my scanner machine, for example, /dev/scanner is a symlink to /dev/uk0, and /dev/uk0 is mode 600 owner mouse. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> /dev has a few reserved directory (like /dev/id). You have no >> freedom there. Any access other than that goes to devfsd. It has >> knowledge equivalt to sys/arch/*/conf/majors.* as reference. And it >> tracks mknod(2), rename(2), etc per-mount point. >> When you do mknod(/dev/wd0a); rename(/dev/wd0a, /dev/woah0a); >> open(/dev/woah0a), devfsd resoves it by using DBs and converts it to >> something like /dev/default/wd0a and pass it back to kernel. I'm a little confused, here. How can chmod and chown on /dev/wd0a do anything useful if /dev/wd0a just gets redirected to (say) /dev/default/wd0a? Removing access helps in only a few cases, because someone wishing to bypass the removal can go directly to /dev/default/wd0a. And granting access doesn't help either, because the access will fail on /dev/default/wd0a even if it doesn't on /dev/wd0a. Unless I've misunderstood something >> You have to shutdown cleanly, otherwise you lose DB. > Sweet jesus. Talk about brittle solutions... Well, yes. But research efforts are like that. Robustness is pretty much necessary for production use but not for the stage this appears to be at. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> dev_t will be no longer used. > I'm not sure if something that blatant (unqualified) is actually what > you meant to say, but if it was, you cannot do that. I don't see why not. It breaks a few things, but only a few. > dev_t (however poorly designed you might think it to be) is a part of > the kernel/application API that has been there forever, and is not > going away any time soon. dev_t was, and is, a kludge, to deal with devices in the relatively primitive filesystem Unix used back in its early days (well, I think they might have been ints then, rather than dev_t, but the difference between the two is trivial). It's good enough for most purposes and its problems have been relatively minor so far, so it's survived, but there's nothing sacred about it. Everything starts somewhere. I would never go near Uebayashi-san's devfs in any of the incarnations described so far on a production system. But I think it's high time someone started thinking about, and experimenting with, alternatives to traditional device nodes and device numbers, and I'm glad to see this happening. If and when this gets to the point of being contemplated for production use, that is the time to worry about compatability with historical practices and decide whether historical compatability must be maintained or an incompatability is acceptable. There have been flag days before and there will be again; doing away with dev_t might - or might not - be one of them. > Stuff like "find -x" needs to keep on working (that uses dev_t), find -x might need to keep working (or might not; if filesystem mounting changes sufficiently it may no longer make sense, not that changes filesystem mounting seem to me to be part of this). There is nothing that says it has to continue working with exactly the same dev_t-based implementation it traditionally has - and even if it does, that needs dev_ts only for st_dev fields, not for special device nodes in the filesystem; the use of the same thing for both is a historical accident that I see no particular need to preserve. find -x cares about dev_t only in the sense that it equates "a.st_dev==b.st_dev" with "a and b are on the same filesystem"; something like indices into an array of mount points, or event-of-mounting serial numbers, would work equally well for those purposes. > and for that matter, doing a backup of a device tree using cpio, then > restoring it later (however insane it really is to use cpio for this > kind of purpose) needs to keep on working. Not given devfs. With a devfs, backing up device nodes makes about as much sense as backing up AF_LOCAL sockets does now. > All of this usually turns out to be really hard ... and with that in > mind, my second hint - when you see an interface that has been around > for a very long time, and is still being used, essentially > everywhere, [...] [it] just might be the interface that is actually > best for the usage it gets [...] A valid point. But it could also be that nobody has thought radically enough to come up with the interface that _is_ better - somewhat a la "your idea is crazy, but not crazy enough to be true". Most research experiments go nowhere. But they must be done, or the few that do turn out to be important would never happen; almost by definition, nobody knows ahead of time which research experiments will turn out to be useless and which ones will turn out to be advancements in the state of the art. With that in mind, I'd say that the more radical Uebayashi-san's devfs is, the less like past (failed) attempts at devfses it is, the more likely it is to turn out to be a better way. Eliminating (this use of) dev_t is an example. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
First, a note - I asked a Linux person I work with why the penguins switched from devfs to udevd. He said that it was a question of pulling relatively complex policy issues out of the kernel into userland, the stance being that things like "users in group pix should be able to access any USB scanner or camera devices that may appear" do not belong in the kernel. I'm sure this forms an argument of some sort for NetBSD's purposes, but I'm not sure which way. bqt wrote, of devfs and persistent state, > So, what we have basically done, at that point, is to reimplement > what we already have, but in a more complex way. > [...] > Nah, I don't see any gains. Only losses. The current entries in > /dev is working better than this, in combination with MAKEDEV, [...] For your use cases, yes, perhaps. My use cases too, most of them at least. But there are other use cases (some of them reasonable, even :) which the traditional /dev does not support well, such as the "I want the disk with UUID xyz to appear at some fixed place regardless of whether it's on SCSI, USB, firewire, bluetooth, or what" one that's been mentioned upthread. Those use cases, the ones /dev does not handle well, are what are driving devfs. It may be that a devfs is not a good way to handle them. But /dev definitely is not; I don't see much alternative but to keep trying various things until someone finds something better. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> This could also enable you to do >> mount -t devfs /etc/devfs-bindchroot.db /var/chroot/bind/dev >> for example. > I don't think a static database will cut it. What happens when > someone attaches a new USB stick and devfs generates a bunch of new > nodes? What ownership and permissions should they get? Presumably the database holds, among other things, information specifying whether new nodes will appear in such a case, and, if so, what ownership and modes they'll 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: (Semi-random) thoughts on device tree structure and devfs
>> I think the "pseudo-device" abstraction is unnecessary > I think it makes sense, because it allows to limit use of the > interface-attribute-less "root" to a minimum. There is a reason that > many/most ports use just one "mainbus" at root. That doesn't make the pseudo-device abstraction necessary. I've sometimes wondered why pseudo-devices weren't handled by creating a pseudo-bus for them to attach at; I did that once, and it was no more than an afternoon's work to have pseudo0 attach at mainbus0 and then my device attach at pseudo0. (I did this because I needed a struct device, but there's no reason it couldn't have been done instead of creating pseudo-devices as we know them today.) /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> have pseudo0 attach at mainbus0 [...] >> I did this because I needed a struct device > That's what attach_pseudo does... I probably could have done it that way, but it looked easier to do it as a pseudo-bus, and for the purposes at the time, the method didn't matter all that much. > I think it makes sense to have some way to create a device hierarchy > without pretending that it is connected to the platform's physical > main bus. mainbus0 does not necessarily correspond to any physical bus. There is other precedent for things in the autoconf tree that do not correspond to anything physical, such as wsdisplay. (Or, more precisely, corresponds to the same physical thing as something else.) /~\ 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: (Semi-random) thoughts on device tree structure and devfs
> (1) dev_t cannot go away, because a fairly fundamental guarantee in > Unix is that two files are the same if stat returns the same (st_dev, > st_ino) pair for each. This dev_t does not have to correspond, though, to anything else in the system. > (3) It is also necessary that device nodes continue to appear as > device nodes to stat (S_IFBLK, S_IFCHR, etc.) No, actually. See below. > because assorted regrettable things happen if e.g. disk partitions > appear to be regular files. Oh, they probably shouldn't appear to be ordinary files. (I'm not convinced they can't be; those "regrettable things" could be looked upon as things needing fixing upon switching paradigms.) They need not, however, be traditional character or block device "files". Indeed, I can't offhand see any reason why userland has to even be able to tell whether two of them are the same or not (though it can help at the human level in some cases); as long as opening one connects you to the correct driver, they could be pretty much anything. stat() returning an st_rdev is another of those implementation details that is not necessary but which people have trouble letting go of because they're not willing to bite big enough bullets. procfs and kernfs are examples of filesystems which illustrate that it's possible to have a non-"device" entities in the filesystem which, when opened, connect to specialized code. Doing this with a devfs might even involve creating a new type of filesystem entity (S_IFDEV, say), though that's quite possibly not necessary. > [vino] did point out at least two important points in addition to the > ones above. > (1) Attaching a device into devfs and attaching a fs into the fs > namespace are fundamentally the same operation. Only at a very general level, the level of "new stuff appearing in the filesystem", but at that level open(,O_CREAT,) also qualifies. So do other calls; perhaps most relevantly here, consider mknod() - some of the ideas mentioned upthread have involved a userland daemon that actually does use mknod() to create new device nodes. > (2) Trying to support both dynamically loadable drivers and > automatically named device nodes causes chicken-and-egg problems. > (If a driver isn't loaded, it has no name entry, and therefore you > can't cause it to be loaded by touching the name entry...) That actually does not follow. Attempting to look up the name (as opposed to doing something with an existing name) could be what triggers the load. Of course, that means that the name exists in some sense, but that sense does not have to be one that's visible to userland (while you may want an administrative interface that lets you see them, it is in no way essential). /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> [st_dev] does not have to correspond, though, to anything else in >> the system. > Not really, no, but it may as well be the same as what's in st_rdev. If there still is an st_rdev. I see no particular reason that needs to be preserved. > The files in procfs and kernfs are for the most part semantically > equivalent to real files even when they're virtual or dynamically > generated. Devices frequently have other properties. Disagree. Writing to real files does not, for example, change the system hostname or alter a process's registers. In fact, that sounds a lot like the kind of dangers that inhere in writing to devices indiscriminately, doesn't it? >> [...] devfs might even involve creating [...] (S_IFDEV, say) > I don't see any point at all in renaming S_IFBLK/S_IFCHR. In terms of the end state achieved, neither do I. But there can be value in that programs that haven't been ported are more likely to misbehave if they see a "name" (by which I mean S_IFCHR and S_IFBLK) they think they know the semantics of but with different semantics than if they encounter something they don't recognize. > [...], and any new device type would have pretty much the same > semantics anyway. In some respects. But lurking under all this has been doing away with st_rdev, which for some programs is a radical enoguh departure that a new name is deserved. (Others won't care, but I suspect most of them don't go looking at st_mode.) >>> (1) Attaching a device into devfs and attaching a fs into the fs >>> namespace are fundamentally the same operation. >> Only at a very general level, [...] at that level open(,O_CREAT,) >> also qualifies. So [does mknod()] > Those are different in a fairly basic way: they create an object > within an existing filesystem namespace, as opposed to binding a > foreign object into the namespace. I'm not sure I'd call a filesystem a "foreign object". If that's fair, then the filesystem namespace is _all_ "foreign object"s, and the "foreign" adjective no longer really means anything there. > A traditional device node is also a binding of a foreign object, but > it does it by creating a proxy object in an existing filesystem. I'm not sure how fair it is to call it a "proxy object", any more than an S_IFREG inode is a proxy for the big array of bytes (stored elsewhere on the disk) that make up the file's contents. Alternatively, they're all proxies, and the adjective becomes pretty much pointless. > Devfs schemes that don't abolish the proxy tend to get in trouble > because it's too many layers of indirection. (This is not the only > problem, but it's *a* problem.) Devfs schemes that do abolish the > proxy eventually discover that the fs part doesn't actually do > anything besides reimplement mount poorly. > This leads to a non-devfs architecture where device nodes are mounted > in /dev. Well, I'm not sure I'd call it "non-devfs", in that you're basically creating either one devfs per device or a devfs which exports only one device per mount, depending on how much of the device-specific part you consider to be part of the "filesystem" that gets mounted. > The remaining trouble arises because they have to be automounted, Well, they don't, really, but not automounting them doesn't solve any of the things devfs-style work is attempting to solve. > As I pointed out somewhere the other day [...], automounter config is > a previously unsolved problem. Not all that unsolved. I've used at least two automounters, each of which solved it well enough for their purposes. Device automounter config *is* unsolved - in exactly the same way that devfs config is unsolved. See below. > I think that approach is ultimately workable without major problems, > unlike ~all devfs schemes, but getting it right remains a research > project. I don't see any real difference between an automounter mounting devices into /dev individually and a devfs making devices appear under a devfs mount. It would even be just a relatively trivial bit of coding to make them accept the same config-file syntax. >> That actually does not follow. Attempting to look up the name (as >> opposed to doing something with an existing name) could be what >> triggers the load. > But what do you load? The same thing you would have loaded for the same name in a "touch the existing name and it autoloads" scheme. >> Of course, that means that the name exists in some sense, [...]. > If the name exists, it's not clear that there's anything (else) > either hard or wrong about making it visible to userland... Well, there may be value in its not appearing in readdir() output. /~\ 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: (Semi-random) thoughts on device tree structure and devfs
>> In some respects. But lurking under all this has been doing away >> with st_rdev, which [...] > Well, no, we're doing away with a specific interpretation of the > contents of st_rdev. Getting rid of st_rdev itself doesn't serve much > further purpose. If we do away with device numbers - I think that was mentioned - what point does st_rdev have? What meaningful values could you put there? The only fundamental purpose they (as used here) serve is to handle the mapping between filesystem entities and driver instances, and that's something that can, and maybe even should, be done differently. >> I'm not sure how fair it is to call it a "proxy object", any more >> than an S_IFREG inode is a proxy for the big array of bytes (stored >> elsewhere on the disk) that make up the file's contents. > But that big array is part of the conceptual entity that the inode > represents. And the device driver is part of the conceptual entity that a device inode represents. > The driver pointed to by a device special file is not part of > anything in the filesystem. Where it is stored is an implementation detail. (And, if it's autoloaded, the driver itself may very well be in the filesystem. Depending on what the driver does, the object, if any, backing it also may be; consider vnd(4).) >> Well, I'm not sure I'd call it "non-devfs", in that you're basically >> creating either one devfs per device or a devfs which exports only >> one device per mount, depending on how much of the device-specific >> part you consider to be part of the "filesystem" that gets mounted. > No, there is no devfs, there are just specfs vnodes that are mounted > directly in /dev. Depends on exactly what you include under the "devfs" name. There is no devfs in the sense of something being passed to vfs_attach(), but it seems to me that that, like the existence of vfs_attach() at all, is an implementation detail; there is code (mostly in the automounter) that performs the functions we have been attributing to a devfs, and in that sense there's a devfs. >> I don't see any real difference between an automounter mounting >> devices into /dev individually and a devfs making devices appear >> under a devfs mount. > Maybe, but if so what purpose does the devfs serve other than to be > too many levels of indirection? I'm not convinced "too many levels of indirection" is fair - and, even if it is, I'm not convinced individual device mounts aren't approximately as bad in that regard. The main purpose it serves, it seems to me, is to collect the relevant code together. Deciding whether to implement the loose conceptual devfs as individual automounted device nodes or a single devfs mount strikes me as a bit of a toss-up; either can perform the fundamental function of a dynamic mapping between filesystem-namespace strings and device drivers. I'm perfectly willing to accept your experience that the single-devfs-mount has operational problems, but, pending someone trying it, I don't believe that the other way doesn't. /~\ 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: NetBSD & binary [was Re: config(5) break down]
>> Let's instead ask us who, and why, some people do drift over to >> NetBSD? I would say that a large portion of those are people who >> for some reason or other have gotten tired of the magical modules, >> autoconfiguration, and magic tools that manage the system for you, >> and who wants to have better control and understanding of the >> system. > Absolutely! > Thanks for these wise words, johnny. "What they said." Thank you, Johnny, for putting it so eloquently. This is very much what bothers me about the directions NetBSD is headed, and has for quite a while: it appears to be trying to turn itself into Yet Another Unix Variant, different from Linux and Solaris and their ilk only in the brand name on the case. People say things like "we'll never win over the Linux users without $FEATURE!", which makes me say "why do you want to?". If I want Linux - or Solaris, or any of various other Unices - I know where to find it; if NetBSD succeeds in turning into a Linux - or whatever - clone, it will have lost the reasons it previously gave me to prefer it. "But we're not trying to do that!" Enough of you are that that's NetBSD's direction. You're trying to come up with point-and-drool installers. You're trying to fully support "desktop environment"s. You're trying to make system administration easy for non-sysadmins. You are, in short, trying to give it the things I picked NetBSD to get away from, the things Johnny summarized so well: lots of magic code doing things users are not only not expected to understand but are expected to not understand (and under whose hood prying is not supported). /etc/rc.d/*. Modular kernels. Sysinst. build.sh. I don't want a system that has any code under whose hood prying is not supported; if the answer to "I'm having trouble with $FOO" is "messing with $FOO is not supported; use our magic code instead", that's a bug as far as I'm concerned. I've seen it called elitist to prefer, for example, installing by hand. I can understand that point of view, but I think it misses the point fairly fundamentally. It's the difference between inclusive and exclusive - I don't want to keep hoi polloi out by demanding understanding before they are worthy to (say) install NetBSD; rather, I want to bring them in by imparting that understanding, with things like manual installation serving as teaching (and self-testing) tools. Nothing teaches like experience. Yes, this excludes the people who don't understand and don't want to. To steal a term from marketing, I don't think NetBSD should try to serve that market segment; it's already well-served by others, and I see no percentage in trying to join them. It doesn't serve them better (indeed, by adding yet another alternative they neither are nor want to be competent to choose among, it serves them worse) and it doesn't serve NetBSD (people who don't even want to understand are among the least likely to turn into developers and contribute back). So what's to like? /~\ 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: config(5) break down
> (What the figures also revealed was that a number of the ports had as > close to zero downloads as matters. Which is, to be frank, a red > flag for those that are not maintained.) You appear to think that no downloads equals no ousers. I submit that this is an invalid inference, especially among the hobby users that make up most of the userbase for most of our ports - many, perhaps even most, of them will upgrade from source and thus will not show up in per-port download statistics. /~\ 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: Debugging threaded processes
> What's happening is that the signal code (5) is written into p_xstat, > and then the LWP is stopped. > Unfortunately, p_xstat is also used to carry a signal delivered from > GDB to the process (as the fourth argument of ptrace() P_CONTINUE > function). > So what happens, if I correctly interpreted my debug sessions, is > that one thread hits the breakpoint, sets p_xstat to 5, calls > sigswitch() to get some other LWP scheduled. However, the LWP that's > picked is one of the other threads for the same process. It's > continuing from a break, so it calls sigchecktrace() to see if gdb > gave it a signal. [...] It seems to me that the basic problem here is that the kernel is trying to use a single variable - p_xstat - to carry more information than a single variable can carry; I suspect there are plenty of other cases where two things can collide over it. Consider thread A stopping, then thread B stopping before anyone has a chance to look at p_xstat from thread A. It seems to me a separate p_xstat needs to exist for each thread, which your description seems to imply is not the case. Mind you, I haven't read the code; this is based on what I read into your description, nothing more. /~\ 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: Dead ports [Re: config(5) break down]
>>> [...] sun2, pmax, algor, etc. [...] >> Right, and these dead ports must be euthanized. > For those single developers who still have such machines, as a > "hardware replacement" and moral compensation, TNF could buy some new > ARM or MIPS board for hacking. Would be a win-win case, would not? Wow. Talk about missing the point. I run NetBSD...well, I run it for multiple reasons. But the one that's relevant here is the hobbyist reason: to do something at least nominally useful with that old hardware. (Like most hobbies, this is fundamentally emotionally motivated, so trying to understand it from a purely rationalist standpoint is probably pointless.) If NetBSD loses interest in being that OS, it loses its value in this regard; providing me with different hardware that NetBSD *does* make useful is a kind thought, but utterly beside the point when it comes to support for the old machines. Given reason to think that $PORT does not actually have any users, perhaps. But, as various people have pointed out, lack of downloads of binary builds is hardly evidence of that. I've got pmax hardware that I'd be using - under NetBSD - if I had the leisure to figure out what was wrong and, probably, swap parts so as to make a working machine, and I would not be doing any pmax binary downloads to do so. I can't tell for sure, but I quite probably have at least one or two of the ports hiding in that "etc" as well - vax in particular; I still have a MicroVAX-II, and if NetBSD desupports it, that will lose NetBSD a pair, not convince me to switch to some "modern" machine instead. _You_ may think of computers as just abstract supplies of computrons, but not everybody does. ...well, possibly if the "modern" machine plugged into the Qbus. Give me an ARM or MIPS board NetBSD runs on with a Q22 interface and I'll be very interested indeed. /~\ 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: config(5) break down
>>> Could this be resolved by adding a "get label" ioctl that could be >>> used on any device? >> That's part of the plan of "my devfs". > yuck. Agreed. For one thing, you can't ioctl anything until you open it, which is a nontrivial operation for many devices - and closing it when you're done is a nontrivial operation for even more devices. > One of the nice things about having symlinks, instead of requiring a > new ioctl, is that you don't need any special tool to see how things > are connected together: you can just use ls. I just had a thought. When symlink mode bits went in, I thought about possible meanings for the set-id bits; I think they are a solution that has just found its problem. The principal (only, as far as I can see) reason why the "symlink into a devfs tree" paradigm isn't good is that it breaks permissions: the devfs nodes' permissions will either allow access they shouldn't or deny access they shouldn't, with no way for the symlinks to fix it. But if the set-ID bit on a symlink means that the symlink's owner is used for the access to the linked-to thing, then all devfs nodes can be owner root mode 600 and user-visible device nodes can be setuid-root symlinks. Then the permissions on the symlink control access. I'm not sure I like it - I think it makes more sense to have the set-ID bit control the rest of the path walk rather than access to the thing at the end of that walk - but that can be dealt with either of two ways: either devfs mounts are mode 700 directories containing mode 666 devices, or the set-ID bit *does* control the path walk - but the sticky bit, if set, says it also controls the access at the end of it. /~\ 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: config(5) break down
> But C include files are a disaster - [...]. > As a user of the things I'd much rather all that just happened > automatically, when I use fopen() if the compiler needs stdio.h, it > should just go and get stdio.h - it's absurd to make me explicitly > say I need it. That means that either: (1) Certain "blessed" libraries (stdio, in your example) more or less have everything they export turned into reserved words, not usable for other purposes. Non-blessed routines work the way they currently do. (2) The compiler knows about all include files everywhere - effectively, (1) with everything being blessed. (3) There's something else you do to make the link between the fopen name and stdio.h (or wherever stdio's declarations are kept). Of these, (1) is perhaps easiest, especially if "blessed" is defined as "in the C standard" or "in POSIX" or some such, thus avoiding bikeshedding about what gets to be blessed. However, it has two problems: it makes it impossible to write routines of your own with the same name as a "blessed" routine, even if you're not using the library in question (for exmaple clear(), erase(), and addstr() are all routine names I very plausibly might use in a non-curses-using program.) We have enough expropriating of perfectly good routine names going on already; at least twice I've tried to port a program forward only to find that the new OS version has taken over a used-to-be-user-namespace name the program used. It also doesn't fix the whole problem, leaving the current situation in place for everything but the magically blessed files. As for (2), that's basically impossible to implement unless you forbid programmer-provided include files. This leaves you with no way to implement the functionality such include files provide today. And as for (3), that's basically just a new spelling for #include; it doesn't really fix anything. > For C, because of the nature of the world 30+ years ago, and > development since, there's nothing we can do about it. But copying > that as if it was a great system would be absurd. I think it's less a matter of being stuck with history and more a matter of the goals being very different. The constraints affecting C includes and driving the design of the paradigm are substantially different from those behind config's files.* files. (This is not to say that C-style includes are wrong for config, just that they're not automatically right either.) I don't really have a comment on the question of config's input syntax. I think it's already split up too far; on multiple occasions I've had to "find /sys -name files.\* -print | xargs mcgrep -H SOMETHING" to find the config lines for something. However, changes to config are unlikely to affect me, so it doesn't matter in a practical sense. /~\ 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: box drawing characters vs. WSDISPLAY_FONTENC_ISO
> On 2nd thought - how likely are we to ever have real life fonts with > character numbers above 0xff? "Ever"'s a long time. I don't expect it to be more than another decade or two before <16-bit characters seem a quaint archaism. (Though perhaps the "we" of that question won't be around by then) Of course, then, people will be saying the same thing with 0x...all we learn from history is that we never learn from history. /~\ 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: bus_space(9) types and printf()
> Or add a MD function to convert a bus_space_tag_t to a value that can
> be printed with (say) %p in MI code that includes most of the useful
> info.
I've felt, in recent years, that printf is annoyingly weak in some
respects. For these purposes, it would be really nice to have a format
specifier that does callbacks, perhaps something like
void print_thing(FILE *, void *);
printf("...%~...",...,&print_thing,(void *)thing,...)
Or perhaps void print_thing(void (*)(const char *, ...), void *) (whose
first arg is printf-signature).
Perhaps kernel printf should grow such a thing?
/~\ 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: $ORIGIN (was: Re: make: ensure ${.MAKE} works)
>> To wit: as far as I can tell, having been wading around in that code >> recently, the only problem with what we have is that if the path >> sent back by namei isn't absolute it needs a getcwd() stuck on the >> front of it. >> Is it reasonable to just do that? I don't think so. It would be a regression in that it would break things in no-path-up-to-/ situations; it also would either fail or expose paths that shouldn't be accessible in path-to-/-isn't-readable situations. > Why not get the kernel to keep a reference to the vnode of the > directory that contained the process image? > Then use some flag to open() (or similar) to open a file relative to > that vnode? Hacking on namei() just to get an absolute path in $(.MAKE)? That seems like a way-overcomplicated fix to a non-problem. I don't see what's wrong with just documenting that $(.MAKE) may not be an absolute path under circumstances that cause getcwd() to fail and letting it go at that. /~\ 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: xsane locks up NetBSD, ulpt and ugen on same device
> Does anyone have a working scanner? Please let me know what brand, > model, and how. Thanks! Do you mean "working scanner" or "working USB scanner"? Because I have a SCSI scanner that's never given me any trouble; if that would help any, let me know and I can dig out details. /~\ 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: Adding mouse sensitivity adjustment to wsmouse
> does X have any way to do mouse scaling, Not very, not core X at least. ChangePointerControl allows defining a threshold above which pointer motion is accelerated by a specified rational fraction (or decelerated, I suppose, if a server feels like implementing fractions <1). However, that's not much use here, and applies to only the core pointer anyway. The input extension may be more elaborate, but I really know just about nothing about it - even the relatively anciet server I use offers extensions I've been unable to find documentation on. (Indeed, of the 16 extensions offered, I've found useful documentation on two.) So yes, I think this would be appropriate for the kernel driver. > how does GNOME manage it, for example? Probably by blindly assuming it's running on Linux x86. :-þ /~\ 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: WAPBL and IDE mac68k
> It happens even when I try to boot to single user mode because I see > the message saying "/: replaying log to memory" right before it > panics. Not sure why the journaling stuff happens when booting in > single user mode without mounting any filesystems, but that's what it > is. You can't boot without mounting any filesystems at all; / must be mounted, at a minimum. > When I moved the drive to the same machine's SCSI bus, it works fine > with any kernel, so this is specific to the IDE bus of the Quadra > 630-type machines. What kind of disk is it that can sit on either SCSI or IDE? Or do you have some kind of adapter in front of it in one case? Could the adapter be related? > (1) How does one start up in single user mode WITHOUT filesystems > getting read? One doesn't. You need to get / from _somewhere_. Perhaps for your purposes it might be a good idea to boot with / on NFS? I don't recall enough of mac68k to say how, but most ports have _some_ way to specify "prompt me for root &c" when booting. > (2) Who knows enough about WAPBL and IDE busses to guess where to > look for a possible solution to this problem? Not me. /~\ 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: remote kernel debugging over a network
> I have to make a decision about the protocol that will be used for > remote kernel debugging. > My question is: Should I go with a custom protocol (+ a daemon that > proxies to TCP), or should I go with TCP directly? My opinion, which is probably worth approximately what you paid for it: custom protocol built directly atop Ethernet (ie, not IP-based). It seems to me that, for this application, the downsides of TCP outweigh the upsides. > (TCP is a necessary part, because gdb has a built-in ability to speak > its remote debug protocol over TCP.) I would disagree that that makes it a necessary part. You could use something other than TCP - if gdb supports serial lines, for example, you could use a pty; even if gdb doesn't support anything but TCP out of the box, you could always hack on gdb as necessary. It's probably *desirable* to use something gdb supports out of the box, yes, but it's hardly *necessary*. /~\ 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: remote kernel debugging over a network
>> My opinion, which is probably worth approximately what you paid for >> it: custom protocol built directly atop Ethernet (ie, not IP-based). >> It seems to me that, for this application, the downsides of TCP >> outweigh the upsides. > It seems to me that something over IP nonetheless would be hugely > convenient... In a few respects. It would also be hugely dangerous in other respects (both mostly deriving from the same properties, at least for the ones I have in mind). For these purposes, I come down on the side of something non-routable, this reinforced by the relative simplicity of not having to implement neighbour discovery and whatnot (or ARP, if you want to go v4, not that ARP is all that much easier). But, as I remarked, this opinion is probably worth approximately what you paid for it. /~\ 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: remote kernel debugging over a network
IPKDB used [...]. [...] easy to support a single IPsec ESP [...] >>> [...] >> [...] > I must say, though, that the more I think about it, the more I'm > concerned about replay attacks. You suggested that ESP replay > prevention be disabled, and that is in fact consistent with the ESP > specs when static keys are used. I think we need to think, hard, > about what we want to do here. You are beginning to see, maybe, why I prefer something _not_ built atop IP. It's a lot easier to ignore this kond of threat when you don't have to even think about anything beyond the local layer-2 broadcast domain. While of course nothing is perfect, I think the number of cases where you want the routability of IP but have nothing on the local broadcast domain that can proxy is small enough that the cost of writing them off outweighs the cost of dealing with the issues that using IP raises. /~\ 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: remote kernel debugging over a network
>> While of course nothing is perfect, I think the number of cases >> where you want the routability of IP but have nothing on the local >> broadcast domain that can proxy is small enough that the cost of >> writing them off outweighs the cost of dealing with the issues that >> using IP raises. > Proxies raise their own set of issues. True enough. But I also believe that for IP access control, you will never find a one-size-fits-all solution, and I would very much prefer to have that access control decision in a regular userland program on a presumably stable machine, rather than in a deliberately-cut-back protocol stack in a severely restricted environment on an inherently unstable machine (any machine where kernel debugging is in progress can, I think, be considered inherently unstable). Of course, the converse is true; an Ethernet-layer protocol will not fit all situations either - for example, the network uplink may not be Ethernet at all, maybe not even vaguely Ethernettish - but that's where judgement comes in. While I wouldn't say I'm unshakeable in the opinion, I currently believe that the closest thing to a general-purpose solution to this problem is Ethernet-layer. /~\ 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: remote kernel debugging over a network
Most of what I'm writing here has already been brought up elsewhere in the thread; I'm collecting it here as a response to the specific questions jgordeev asked. Those who've read the rest of the thread will probably find nothing new here. >> My opinion, which is probably worth approximately what you paid for >> it: custom protocol built directly atop Ethernet (ie, not IP-based). > You are concerned about security? Among other things. Security is a concern, yes, but I'm also concerned about code size and complexity in the kernel, especially debugging code. It's bad enough to be talking Ethernet at all; I'd be very reluctant to either try to shoehorn another IP stack in there or use the main IP stack. Even a comparatively small and cut-back IP stack is a relatively large and complex blob of code, much more than I would like to have to deal with in a debugger interface. >> It seems to me that, for this application, the downsides of TCP >> outweigh the upsides. > What downsides you have in mind? Mostly covered in the previous paragraph: the (in)security of using something routable and the code size/complexity and associated reliability. There is also the point that TCP includes a lot of logic designed to support use cases which are pretty much totally irrelevant for this purpose, so either you include even more (unnecessary for the task) complexity or have a not-quite-TCP stack with all the inteoperability headaches that implies. > gdb does support serial lines. I knew that pty can be used for > emulating a terminal, but I was unsure whether it can be used for > emulating a serial port. Actually, a pty always emulates a serial port. ptys are used when emulating terminals only because a terminal has to be connected somewhere to be useful, and the commonest case wants to connect the (emualted) terminal to the host the emulator is running on, which is exactly the kind of emulated serial port a pty provides. > Hacking on gdb is not an option. I will not do it, Fair enough. > and even if I did it, who would maintain it? Two potential answers: (1) gdb's upstream. (While I don't know how NIH the gdb folks in particular are or aren't, in at least some cases upstream distributions have adopted changes.) (2) The same person or persons who maintains the other code you're creating. Of course, that's not to say either one would, or even should, happen. And, given your lack of desire to do it to begin with, the question is pretty much moot. :) /~\ 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: why not remove AF_LOCAL sockets on last close?
>>> Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL >>> sockets from the filesystem on last close? Well, I wouldn't expect it to be easy; it means that every AF_LOCAL socket needs to keep track of its pair. This leaves open the question of what to do if it has multiple links when whatever point you consider "last close" arrives. For most purposes it would probably be good enough to do something like "if the originally-bound name in its original directory still refers to the same socket, unlink it; ignore other issues". >> If you want to do that, wouldn't it be easier to just go the Linux >> route and move them into a separate (virtual) namespace completely? Easier? Maybe. But you'd lose the (currently almost free) leveraging of the other attributes of overloading the filesystem namespace, such as permissions checking. > Linux does that? I ran this test program on a Linux system and got a > socket in the filesystem and the same results. I haven't tried it myself, but I've been told that Linux does that *sometimes* - specifically, if the pathname begins with a NUL but the address length indicates that there's more pathname following it. I don't know whether there's anything like a hierarchical filesystem namespace there or whether they're just opaque octet-string blobs. /~\ 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: why not remove AF_LOCAL sockets on last close?
> But I agree that if leaving the sockets around permits no interesting > feature whatsoever (i.e. it doesn't even serve for SO_REUSEADDR), I've been trying to think of any such feature since this discussion started. So far i've failed. > it very well could be a design or implementation bug, I suspect it is actually not so much a design or implementation bug as it is a historical accident: I suspect the initial implementation made them a new inode type because it was a cheap and easy way to get a namespace for free, and didn't bother with the impedance mismatch between filesystem semantics and (other-AF) socket semantics because it was just a quick experimental hack. Then, as often happens, the quick experimental hack persisted long beyond its initial experimental phase, with nobody fixing the semantics because everybody was used to them and software was written to deal. As I mentioned in another message a few minutes ago, I think this is not easy to do fully right - indeed, it's not totally clear what "right" is in all cases - but I do think it is easy to come close enough to be useful. /~\ 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: why not remove AF_LOCAL sockets on last close?
>>> A reason might be that every other system behaves the same way and >>> being different will just lead to non-portable code. >> Non-portable *how*? What exactly would happen? > I don't know, and if you've got an argument that code written for > either behavior will be ok both places I don't have a problem with > it. The only thing I can think of is that code that does an explicit > unlink and checks for error on the unlink may complain, which is > pretty mild. Well, code that expects the automatic unlink is liable to break unexpectedly (and probably cryptically) on "traditional" systems. /~\ 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: systems hangs with slow disk - how does FS locking work?
> My assumption is that the "big" data block written is devided in > several small chunks (disk blocks, 512 bytes), which will then be > written to disk sequentially, and with the system preempting if > there's other work to do. The preemption would further delay the > writes, but write speed not an issue. Depends. Does the driver do DMA, or does it have to go with PIO? If PIO, you may actually not be blocking all of userland for the whole duration, but it may be getting only tiny amounts of CPU in between each underlying transfer and the next, which may look very similar. Especially if the PIO is slow. Another possibility is that the underlying hardware uses a block size larger than 612, like 2K or 4K, and is doing a read-modify-erase-write cycle for each 512-octet sector. Erases can be slow. /~\ 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
MP locking?
I have some kernel code which was written for a pre-MP kernel; it uses spl*() for locking. I'd like to roll this forward to something at least slightly more modern - specifically, a dual-CPU 4.0.1 machine. lock(9) outlines locking facilities which I believe I can use to do what I want - but there are other issues, such as cache coherency; do I need to do anything special with shared data structures to ensure coherency between processors? Is it enough to declare them volatile, or do I need memory barriers as well, or what? To what extent can I use locks from within code invoked by callouts? /~\ 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: MP locking?
> Having just recently spent quite a bit of time porting a kernel > module from NetBSD-3 to NetBSD-5, and working out a bunch of > synchronization issues, I suggest skipping over NetBSD-4 and going > straight for 5. Noted, though I doubt a major version jump is in the cards for that machine in the foreseeable future. And, really, because it still needs to run in the original pre-MP kernel with minimal changes, what I'm going to be doing is pulling all the locking out so those differences can be hidden from everything but a relatively small and well-defined piece of the code, making further ports to the locking scheme du jour relatively simple. /~\ 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: MP locking?
>> [...roll forward pre-MP code to become MP-ready...] >> lock(9) outlines locking facilities which I believe I can use to do >> [the locking] I want - but there are other issues [...] > You need memory barriers, modern CPUs can do speculative reads, and > some can reorder writes. AFAIK, lock operations act as memory > barriers. atomic ops do not. But are lock calls enough? As I understand a memory barrier (which understanding is mostly based on CPU documentation of barrier instructions), it is not enough, since it does not imply any cache synchronization with other CPUs. If CPU A writes a shared data structure and then issues a memory barrier, either (i) this has no particular effect on CPU B's cache, leading B to possibly use stale data, or (ii) this forces CPU B to discard its whole read cache, incurring a mostly (possibly entirely) unnecessary performance hit. (ii) can be avoided if memory barriers apply to only certain addresses, but, since the locking calls do not take any addresses except those of the lock, the implicit memory barrier you refer to cannot have that kind of information associated with it. (This actually leads me to wonder: are those implicit memory barriers good for anything besides device access?) I find it hard to believe that releasing a lock causes all other CPUs to discard their entire read caches This leaves me with (i). I know some cache hardware does snooping of writes by other CPUs (or, semi-equivalently, DMA engines) to avoid the issue entirely, but I also know some hardware doesn't. How does NetBSD address the issue? The only thing "man -k barrier" turned up, besides a handful of pthread calls, is bus_space(9), which AIUI is not relevant here because these are data structures in ordinary kernel memory, not bus space - am I missing something? Does this just mean that 4.0.1 (which is what I was checking the manpages on) does not support MP on hardware which doesn't do cache snooping, or is there some facility I've missed for arranging for other-CPU cache flushes, or what? /~\ 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: The missing membar_X() directive
> IIRC, you cannot implement RCU in non GPL software (unless IBM gives > approval for it). Why not? Even if it's patented, it's unlikely to be patented anywhere but the USA (certainly the Wikipedia page gives no reason to think so); there's no reason the rest of the world should have to suffer the boneheadedness the USA has chosen to impose on itself. Since NetBSD is a USA entity, there _is_ a reason for NetBSD to put up with the USA's idiocies, but I see no reason someone in the sane world can't implement it and make patches (to NetBSD or anything else) available. I suspect the USA patent is invalid, too, though (especially given its date) it's unlikely anyone with deep enough pockets to take it on cares. /~\ 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: Potential re(4) / netbsd-4 / i386 problem?
> is it possible that the re device is writting past its buffer (via > DMA) and overwriting random memory ? Isn't that one thing the iommu is for? Oh, wait Well, use machines whose designers cut corners on hardware design and guess what happens. Actually, my main reason for writing is to mention that I have a laptop, running 4.0.1, with an re onboard, and have never seen such random crashes. I can give more details if they matter. /~\ 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: RFC: device flavours
> I'm looking for comments about what I call "device flavours". [...] I'm having trouble seeing what this offers over things (like scsibus) where an abstraction attaches at real hardware and then other things attach to the abstraction. > flavour acpiib at pci: acpinodebus > filedev/acpi/acpiib.c acpiib > > flavour ichlpc at pci: acpipmtimer, sysmon_wdog, fwhichbus, hpetichbus, gp= > iobus > filearch/x86/pci/ichlpc.c ichlpc > flavours ichlpc, acpiib > npx*at pcib? > gpio* at gpiobus? > I've been wondering about simply allowing more than one driver to > attach to a device, It seems to me that we already have something effectively the same as that, mediated by a "controller" driver. For example, consider the way, on sparc, zs attaches to the chip and then zstty or kbd or ms attaches to zs (or at least that's how it used to work). You write that > But the main point is that a flavour can be created without the main > driver being aware of it; but, again, it looks to me as though we already have that: to return to the zs example, the zs code does not need to know anything about the list "zstty, kbd, ms" in order for those child devices to work. But I feel certain you are already familiar with all that. So I must be missing something. What? /~\ 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: Potential re(4) / netbsd-4 / i386 problem?
>> Actually, my main reason for writing is to mention that I have a >> laptop, running 4.0.1, with an re onboard, and have never seen such >> random crashes. I can give more details if they matter. > I've got 3 motherboards with re onboard that I've tested, 2 of the 3 > have the problem. I checked the re hwrev and the one that works fine > is 0x2800. The 2 boards that don't work have hwrev 0x3800 > and 0x3C40. The board that's fine is a commercial Intel DG41MJ > while the other 2 are both DFI industrial boards (LT600-DR, LT330-B). My laptop is a Sony Vaio (PCG-5G3L). The re is re0 at pci3 dev 0 function 0pci_mem_find: void region : RealTek 8100E/8101E PCIe 10/100BaseTX (rev. 0x01) re0: interrupting at ioapic0 pin 18 (irq 7) re0: Ethernet address 00:13:a9:f2:6f:af re0: using 256 tx descriptors rlphy0 at re0 phy 7: RTL8201L 10/100 media interface, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I don't see anything there that looks like the rev numbers you're talking about. While now is not a good time, I'll have a look at the code and see if I can find the hwrev value you're talking about and print out its value for my hardware. /~\ 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
envsys issues [was Re: envstat wrong: who's at fault?]
[moved from port-i386]
[me]
>> In passing, would it be appropriate and/or useful to suggest
>> improvements to [the envsys(4)] API? When I was writing code, I
>> found the envsys(4) ioctls to be deficient for my purposes.
[Paul Goyette]
> I'd be interested in knowing in which ways you found the current API
> lacking. [...]
Well, some things are underdocumented. For example, it seems that most
sensors are not in the units specified by envsys_tre_data_t.units, but
rather in 1e-6 of that unit - for example ENVSYS_SWATTHOUR sensors are
not in watthours but in microwatthours - and, as far as I've been able
to find, this factor of 1e6 is not documented anywhere but the source
to envstat(8). Except for temperature, which is specifically said to
be in microKelvins. But others are said to be in volts, amps, etc. To
quote both the envsys(4) and ,
union { /* all data is given */
uint32_t data_us; /* in microKelvins, */
int32_t data_s; /* rpms, volts, amps, */
} cur, min, max, avg; /* ohms, watts, etc */
/* see units below */
If the "micro" is supposed to apply to all those units, not just
Kelvins, then (a) "rpms" needs to be removed from the list and (b) the
wording needs to be improved.
But the one piece I've found so far that isn't just a lack of
documentation (well, unless there are totally undocumented calls) is
that there's no way to fetch multiple sensors' values without potential
for skew between them.. For example, to quote from the code I've been
developing,
prev_charging = -1;
prev_discharging = -1;
/*
* This loop exists in an attempt to avoid getting confused by things
* changing in between fetching one variable and fetching the other.
* It can still get confused if multiple changes occur during that
* interval, but, without some kind of assist from the API, that's
* not fixable. (My preferred assist would be a way to fetch
* multiple sensors' values atomically; failing that, some kind of
* change serial number.)
*/
while (1)
{ charging = get_boolean(SENSOR_CHARGING);
if (charging < 0) return(0);
discharging = get_boolean(SENSOR_DISCHARGING);
if (discharging < 0) return(0);
if ((charging == prev_charging) && (discharging == prev_discharging)) break;
prev_charging = charging;
prev_discharging = discharging;
}
(get_boolean returns 0 or 1, wrapping ENVSYS_GTREDATA, with checks that
the sensor being fetched is of type ENVSYS_INDICATOR and has
ENVSYS_FCURVALID set; the SENSOR_* defines are application-specific).
Or is this fundamentally unfixable because sensors' values are fetched
serially and individually from the hardware with the corresponding risk
at that level too? Then I agree with the remark in the manpage that
some kind of event-stream interface is needed.
/~\ 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: envsys issues [was Re: envstat wrong: who's at fault?]
>> [...] > This is greatly cleaned up in the envsysV2 implementation. >> [...] > In envsysV2, a single call is used [...] Then there's not really anything to discuss, because it's all already been fixed. Excellent. /~\ 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: Modules loading modules?
> We have a modular device driver, let's call it xxxmod. [...] It [] > might attempt to use an optional module (e.g., zzzverbose) to print > some device attachment messages. > First, a required module cannot be optional. If the desired module > is not present, or if it is present but its own > xxx_modcmd(MODULE_CMD_INIT, ...) fails, the failure is propagated > back to the original "outer" call to module_load() which will also > fail. > The second reason why this is not suitable is that the "outer" load > will add a reference to the module, preventing it from being > auto-unloaded. Surely the right answer here is to provide a way to say "refer to this module, but it's ok for its load to fail, and it's ok for it to get auto-unloaded", including passing up whatever information is necessary for the calling module to do something useful in failure cases? It really seems to me that the module system is there to help us, not to shackle us, and that if it has properties which are leading to problems, one of the options we should at the very least be considering is changing those properties. /~\ 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: Potential re(4) / netbsd-4 / i386 problem?
>> I've got 3 motherboards with re onboard that I've tested, 2 of the 3 >> have the problem. I checked the re hwrev and the one that works >> fine is 0x2800. The 2 boards that don't work have hwrev >> 0x3800 and 0x3C40. > I'll have a look at the code and see if I can find the hwrev value > you're talking about and print out its value for my hardware. 0x3400. /~\ 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: fd code multithreaded race?
> So something naiive like this: [...] will give you the wrong result. True. Essentially, you have a shared resource (the fd-number to thing table) which you are using without any locking. Of course there are races! Some threading setups allow different threads to have independent file descriptor tables, which would avoid the issue you sketch (but, of course, introduce other issues). > Never realized file descriptors and threads were so tricky ;) There's nothing special about file descriptors here. You have basically the same issue with any other piece of state which is shared by all threads. To pick two more examples the kernel maintains, working directory and umask. These are a shared resource; like any shared resource, accessing them from multiple threads requires care, and usually locking of some sort. /~\ 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
weird ktrace timestamps?
Is there known to be something weird with ktrace record timestamps under 4.0.1 (i386, in case it matters)? I just did some ktracing (using ktrace -i -p ..., in case it matters) on an i386 machine. The first two lines of kdump -R output on the resulting file were 693 1 xshowppm 0.0 EMUL "netbsd" 693 1 xshowppm -1.96647 CALL accept(3,0xbfbfe90c,0xbfbfe908) The peculiar apparent timewarp made me look deeper. Here's (the beginning of) hexdump -C output on ktrace.out: 06 00 00 00 07 00 01 00 b5 02 00 00 78 73 68 6f |xsho| 0010 77 70 70 6d 00 00 00 00 00 00 00 00 00 00 00 00 |wppm| 0020 8e 89 59 4c 97 15 a1 2a 01 00 00 00 6e 65 74 62 |..YL...*netb| 0030 73 64 14 00 00 00 01 00 01 00 b5 02 00 00 78 73 |sdxs| 0040 68 6f 77 70 70 6d 00 00 00 00 00 00 00 00 00 00 |howppm..| 0050 00 00 8e 89 59 4c 7e 08 a1 2a 01 00 00 00 1e 00 |YL~..*..| 0060 00 00 0c 00 00 00 03 00 00 00 0c e9 bf bf 08 e9 || 0070 bf bf 10 00 00 00 02 00 01 00 b5 02 00 00 78 73 |..xs| Based on , I break down the first two records as 06 00 00 00 ktr_len, 6 07 00 ktr_type, KTR_EMUL 01 00 ktr_version, 1 b5 02 00 00 ktr_pid, 0x2b5 = 693 78 73 68 6f 77 70 70 6d ktr_comm, "xshowppm" 00 00 00 00 00 00 00 00 00 00 00 00(compiler-generated struct padding) 8e 89 59 4c 97 15 a1 2a ktr_time (_ktr_time._ts), 1280936334.715199895 01 00 00 00 ktr_lid (_ktr_id._lid), 1 6e 65 74 62 73 64 record contents, "netbsd" 14 00 00 00 ktr_len, 20 01 00 ktr_type, KTR_SYSCALL 01 00 ktr_version, 1 b5 02 00 00 ktr_pid, 0x2b5 = 693 78 73 68 6f 77 70 70 6d ktr_comm, "xshowppm" 00 00 00 00 00 00 00 00 00 00 00 00(compiler-generated struct padding) 8e 89 59 4c 7e 08 a1 2a ktr_time (_ktr_time._ts), 1280936334.715196542 01 00 00 00 ktr_lid (_ktr_id._lid), 1 1e 00 00 00 0c 00 00 00 record contents 03 00 00 00 0c e9 bf bf 08 e9 bf bf There are two interesting things here: the timestamps in the file do not warp backwards by almost two seconds - but they do warp backwards, by 3353 ns. So, there are two strange things here: (1) that the timestamps in the file go backwards and (2) that kdump prints them as going backward much further than they actually do. This is not just ntpd happening by bad luck to adjust the clock right then; I did another run and got the same syndrome (with a very slightly different time delta) at the same point - the first and second records of the file. Furthermore, the program forks, and the first two records generated by the child show a very similar bogon in kdump output: 693 1 xshowppm 0.04470 CALL write(9,0x806c000,0x2800) 721 1 xshowppm 0.12292 EMUL "netbsd" 721 1 xshowppm -1.97486 RET fork 0 693 1 xshowppm 0.05866 GIO fd 9 wrote 4088 bytes I haven't dug out the underlying records for this case; it's far enough into the file they would be inconvenient to locate. But the kdump output is similar enough that I would expect it to be due to the same cause, whatever it is. Any thoughts? I'll investigate this eventually if I don't hear anything, but it strikes me as reasonably likely that someone will recognize the syndrome and be able to point me in a useful direction. /~\ 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: weird ktrace timestamps?
>> There are two interesting things here: the timestamps in the file do >> not warp backwards by almost two seconds - but they do warp >> backwards, by 3353 ns. > Try a different time counter. See kern.timecounter. kern.timecounter.choice = clockinterrupt(q=0, f=100 Hz) TSC(q=-100, f=1795636350 Hz) ACPI-Fast(q=1000, f=3579545 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-100, f=100 Hz) kern.timecounter.hardware = ACPI-Fast kern.timecounter.timestepwarnings = 0 I switched to TSC and got the same syndrome (well, as far as kdump output goes; I didn't dig into ktrace.out). Switching to clockinterrupt made the syndrome go away, but all the timestamp deltas printed by kdump -R were zero (there probably were a very few that weren't, but I didn't see any of them in a quick eyeball skim). > Is this UP or MP? MP. cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel Core 2 (Merom) (686-class), 1795.62 MHz, id 0x6fd cpu0: features bfebfbff cpu0: features bfebfbff cpu0: features bfebfbff cpu0: features2 e3bd cpu0: "Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz" cpu0: I-cache 32 KB 64B/line 8-way, D-cache 32 KB 64B/line 8-way cpu0: L2 cache 2 MB 64B/line 8-way cpu0: using thermal monitor 1 cpu0: Enhanced SpeedStep (1420 mV) 2000 MHz cpu0: unknown Enhanced SpeedStep CPU. cpu0: using only highest and lowest power states. cpu0: Enhanced SpeedStep frequencies available (MHz): 2000 1200 cpu0: calibrating local timer cpu0: apic clock running at 199 MHz cpu0: 64 page colors cpu1 at mainbus0: apid 1 (application processor) cpu1: starting cpu1: Intel Core 2 (Merom) (686-class), 1795.43 MHz, id 0x6fd cpu1: features bfebfbff cpu1: features bfebfbff cpu1: features bfebfbff cpu1: features2 e3bd cpu1: "Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz" cpu1: I-cache 32 KB 64B/line 8-way, D-cache 32 KB 64B/line 8-way cpu1: L2 cache 2 MB 64B/line 8-way cpu1: using thermal monitor 1 I did consider the possibility that MP was relevant, but it strikes me as highly unlikely that it would migrate between processors exactly there every time (and, apparently, _only_ there). Is it likely enough that it's something else tied to MPness that it's worth trying a test under a UP kernel? /~\ 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: kicking everybody out of the softc
> I've been working in spare moments on lockless code to prevent > storage for a softc from going away while a driver uses it. [...] This looks superficially good, but isn't the cost of the necessary memory barries and cache flushes comparable with the cost of a more traditional scheme? /~\ 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: something really screwed up with mmap+ffs on 5.0_STABLE
> The only difference between the two programs is this: > #if 1 > read(fd, buf, BUFSIZE); > bmem = (void *)buf; > #else > busmem = mmap(NULL, sb.st_size, PROT_READ, MAP_FILE|MAP_SHARED, fd, > 0); > if (busmem == MAP_FAILED) > err(1, "mmap"); > bmem = busmem; > #endif Any particular reason to error-check mmap but not read? Any particular reason to read BUFSIZE bytes but mmap sb.st_size bytes? /~\ 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: ptrace(2) PT_STEP changes and gdb
> Can't you just version it? Rename existing PT_STEP to PT_OSTEP or > something, define PT_STEP with the new value (instead of introducing > new PT_* name)? That works for ABI compatability but not API compatability. /~\ 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: 16 year old bug
>> Fix a 16 year old bug in the sorting routine for non-contiguous netmasks. > Does our IPSEC code actually _use_ non-continguous netmasks? I haven't looked at the IPsec code, so this is a guess, but the wording makes it sound as though this is an implementation technique used internally by IPsec rather than being the externally-visible use of noncontiguous netmasks everyone seems to be taking it for. That said, > and most modern network hardware will turn their nose up at them > AFAIK. IMO anything that pretends to implement IPv4 but which doesn't do noncontiguous netasks is simply broken, I don't care whether it comes from Cisco or Netgear or NetBSD. Not, I suppose, that anyone necessarily cares what I consider broken. Slow-path them. Require a sysctl switch (the way we do for source routes). Fine. But outright desupport them? I'd call that a bug, even if it is done deliberately. /~\ 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: 16 year old bug
> On the other hand, simple non-contig netmasks, with no ambiguity, > certainly were permitted originally. They work just fine. They also > offer essentially nothing over contig netmasks - they're just a > permutation of the bits in the addresses. I wouldn't say _nothing_. See below. > The one (the only) reason they were permitted, that I know of anyway, > was that by allowing them we apparently let some (perhaps > hypothetical) sites implement subnets without altering their existing > IP numbering scheme. I personally never saw such a site, and have no > direct evidence one ever existed (or that anyone ever actually used > non-contig netmasks for this reason) - but that was the argument > anyway. I have. For a significant time (years) I was running my house LAN with a netmask ending in (binary) 11011000, I think it was - a /29 expanded by adding a second /29 from higher up. (The memory is very fuzzy, but 255.255.255.216 looks right.) The reason was exactly this: growing the space without renumbering when the original space's pair had alreayd been allocated elsewhere. Was it necessary? Not for most values of "necessary". Was it useful? Definitely. Not visible outside its parent network, of course, but that's true of most subnetting schemes, including CIDR ones, and it was in live use for years. >> I was actually at the pre-CIDR IETF meeting where it was discussed >> whether to standardize the forwarding lookup for routes with >> non-contiguous masks or disallow them altogether. Out of scope. A host's routing implementation is not visible from the network; it is not a matter for the IETF to standardize. If you want to forbid noncontiguous netmasks in wire protocols like BGP or RIP or whatever, that is in scope, but also irrelevant to what you're describing. >> You are almost 20 years too late to influence that outcome. Irrelevant. Nobody off-network can tell whether I'm using noncontiguous netmasks within my network, so nobody but my co-administrators has standing to even comment on the question. Of course, NetBSD may, if it wishes, desupport them. It also may, if it wishes, desupport netmask boundaries falling other than on octet boundaries. I would call the one a bug just as I would the other. /~\ 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: 16 year old bug
> I believe that non-contiguous netmasks actually are illegal nowadays. Cite? > They became illegal when CIDR was implemented. Implemented? I doubt it. Standardized, at most. But even then, it would take years to eliminate everything that supports them - indeed, I just now tried it and find that NetBSD 4.0.1 appears to support 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: 16 year old bug
>> IMO anything that pretends to implement IPv4 but which doesn't do >> noncontiguous netasks is simply broken, I don't care whether it >> comes from Cisco or Netgear or NetBSD. > For that to work at all across multiple implementations would require > a standard to tell you, when your destination address matches more > than one route, which of those routes takes precedence. That...disagrees with my experience. I ran my house LAN with a noncontiguous netmask for years without any such standard. Worked just fine. Perhaps you meant "to work consistently in certain cases" rather than "to work at all"? /~\ 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: 16 year old bug
> Was [running my house LAN with a noncontiguous netmask], for > practical purposes, unsupportable? Was it something likely to cause > subtle bugs all over the networking stack? Was it something > obsoleted more or less 20 years ago? All yes. Actually, no. Unsupportable? I don't see anything unsupportable about it. Every system I tried (which admittedly wasn't all that many) supported it fine. Even today, I tried NetBSD 4.0.1 (the most recent I have easy admin access to) and it appeared to support it as well as whatever I was using at the time did - though admittedly I didn't actually verify that packets were routed the way the resulting routing table implied. Likely to cause bugs? Nonsense. Likely to expose existing bugs, perhaps. Do you not consider exposing existing bugs a good thing? I know I certainly do. Obsoleted 20 years ago? Perhaps. Strikes me as pretty functional and useful for an "obsoleted" feature. Besides, this _was_ 20 years ago - well, actually more like 15±5; I didn't have much of a house LAN before maybe 1991, and I stopped using the address space this was embedded in sometime around 2000-2001. /~\ 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: 16 year old bug
> Non-contiguous masks can indeed be useful, albeit only in specialized > topologies and networks. I could have used them in a paper I > published just 1.5 years ago. The trouble is that they conflicted > with the routing table definition necessary for CIDR, and CIDR was > and is necessary for the survival of the Internet. Hm? Conflicted how? The routing table structures in use in NetBSD, past and present, seem to handle both CIDR and noncontiguous netmasks just fine - provided, as people point out, you avoid ambiguous cases, but that's inevitable unless and until you pick a rule to resolve the ambiguities. (It doesn't need to be standardized, at least not beyond the boundary within which the noncontiguous netmasks are confined.) After all, CIDR masks are just a special case of arbitrary-bitmask masks; code to handle the latter correctly will necessarily handle the former. (Conversion between bitmask masks and CIDR-style lengths is, or at least can be, just an interface issue.) /~\ 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: 16 year old bug
>>> I believe that non-contiguous netmasks actually are illegal nowadays. >> Cite? > RFC 4632 (CIDR Address Strategy), section 5.1: ...which is titled "Rules for Route Advertisement". (Also, 4632 is a BCP, not a standard.) > " An implementation following these rules should also be generalized, >so that an arbitrary network number and mask are accepted for all >routing destinations. The only outstanding constraint is that the >mask must be left contiguous." With respect to route aggregation in advertisements (ie, exterally-visible behaviour). See the second paragraph of 5.2. /~\ 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: scsipi mid-layer, tagged queueing, and ciss(4)
> It does report the CmdQue bit in the flags3 field of the inquiry, but > leaves the ANSII value in the version field 0 - which indicates the > flags3 field isn't present. The scsipi layer doesn't check the > flags3 value because the ANSII value is < 2, and thus doesn't set the > tagged queueing capability for the device. This sounds to me like just the sort of thing quirks are for. Is there some reason not to make this a quirk? Or Am I Missing Something (tm)? /~\ 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: O_DIRECTORY
> Is there a way to open a directory on which you have neither read nor > write access (maybe not even search access) ? I've thought for some time there sbould be an O_NOACCESS, to open things without any ability to do I/O. The major use for this I've found is opening directories for later feeding to fchdir(), but I suspect that if it existed people would find other uses for it. I'm not sure what, if any, restrictions there should be on it, which is one reason I've never actually tried to implement such a thing. /~\ 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: where is my memory?
>>> total memory = 2047 MB >>> avail memory = 1999 MB >> total memory = 256 MB >> avail memory = 239 MB > Some graphics chips, especially on lower-end machines, use main > memory, thus making it unavailable to the CPU. It's not that simple. I've seen this for a very long time, including on machines with no graphics chips at all, such as 4.3 on a VAX 750. Here's a live example; this is quoted from /var/run/dmesg.boot on a SPARCstation LX that's my desktop at one of my workplaces: total memory = 48688 KB avail memory = 41676 KB That's with a cg6 with its own private framebuffer RAM. /~\ 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: Capsicum: practical capabilities for UNIX
> POSIX.1e "capabilities" are actually coarse-grained OS privileges, Not all that coarse-grained as compared to traditional Unix privileges! > [POSIX-style "capabilities"] solve (or, in some cases, don't solve) > an orthogonal problem in UNIX security: how to decompose root > privilege. Not all that orthogonal. I'd say that they're really solving the same thing, just in different ways and at different levels of granularity, that "same thing" being the question of how to convert the single level of privilege offered by the hardware (user mode versus kernel mode, in Unix terminology) into something more useful. Traditional Unix breaks this into three: kernel mode, root user mode, and non-root user mode. POSIX "capabilities" (which, based on what was said upthread, are remarkably like VMS privileges) break it down a bit further. Capabilities in the sense everyone but POSIX uses the term :) break it down even further and in a somewhat different way, but it's still addressing the same basic problem: how to allow/deny access to resources in a more useful way than the all-or-nothing way the hardware provides. > Capabilities in a classic security sense are unforgeable tokens of > authority that can be delegated. Sounds a lot like POSIX "capabilities" to me - it's just that the authority comes in, as compared to non-POSIX "capabilities", relatively coarse chunks and is passed around in a rather different way. /~\ 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
SLIP coexisting with serial data?
I have a situation in which it would be useful to run SLIP on a serial console. Obviously, this won't work very well at present. (The machine has only one serial port and no useful network interfaces.) I was looking at improving if_sl.c to support encapsulating "normal" serial data on the SLIP's tty as packets, thus merging it into the packet stream. I ran into some problems, but think I can handle them; I'm writing to ask if there's any interest from anyone else in this sort of thing, in upgrading SLIP to support "normal" serial output. I was thinking of making this another protocol type, akin to what I mentioned (probably on tech-net) back in '02 - I just now (finally) filed kern/43959 containing patches to support v6 as well as v4, something that's easy compared to making the tty still work as a tty, but which includes a good deal of multi-protocol scaffolding that's semi-necessary for the way I've been envisioning doing serial data. Thoughts? /~\ 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: SLIP coexisting with serial data?
>> I was thinking of making this another protocol type, akin to what I >> mentioned (probably on tech-net) back in '02 - > > Maybe you could get IETF to standardize an extension to *PPP* :-) > While I hesitate to feed self-admitted trolls :), there actually is a real point lurking here. (a) There's a reason I published my documentation of it as a file in my FTP space rather than trying to get even an I-D created: the IETF's hoops are insane. RFCs used to be people floating ideas. Then they got formalized, so I-Ds were created to be the informal version. But now even I-Ds have accreted too much formality to be useful. (b) I specifically do not want PPP. Hn '02, when I first designed the extension to PPP, I sunk an afternoon into trying to use PPP. My use case then was a hardwired serial line between two ports dedicated to the purpose; I was utterly unable to create a configuration that would come back up seamlessly for every order and timing of reboots. About the only thing PPP would have brought to that use case, if I had made it work, would have been detection of a dead peer, and that was of no value in that case, since there was nothing to do but drop the packets if the peer was dead, and that's exactly what SLIP does. Now, it's possible that I just missed something. But, while no way am I a true expert at networking, I'm pretty good; if I can't make it work in a whole afternoon of trying, at the very least it suffers from being too complicated. As soon as I switched to SLIP, on the other hand, it worked first time, every time. "Too simple to break". (The reason I didn't start with SLIP was that I needed to carry v6 packets. After an afternoon of struggling with PPP, an hour or two of hacking on the SLIP implementation and I had packets flowing.) (c) The IETF lives on "rough consensus and running code". I've got the running code for v6 and thought some people might be interested either in that (hence the PR) or in chipping in on how to multiplex serial data into it. /~\ 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: SLIP coexisting with serial data?
>> I have a situation in which it would be useful to run SLIP on a >> serial console. Obviously, this won't work very well at present. >> (The machine has only one serial port and no useful network >> interfaces.) > Maybe something like SLIRP (http://en.wikipedia.org/wiki/Slirp)? > Haven't used it in aeons and never tried it under NetBSD, though. That is pretty close to sliplogin(8), and it deals with turning a login tty into a serial IP transport; it does nothing at all about encapsulating ordinary serial data that would otherwise be sent down the serial line into something that can be pulled out on the peer. /~\ 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: SLIP coexisting with serial data?
>> I have a situation in which it would be useful to run SLIP on a >> serial console. [...] > Given how rare the situation is, maybe it's best to do the > encapsulation/decapsulation in user mode, and feed into SLIP via a > pty. (I also suspect that the speeds are low, but I know you often > run older machines.) Possibly. I've had remarkably bad luck using TIOCCONS. I'd also rather not wrap the serial data in IP packets. The speeds are as high as the machines involved support, which doesn't say all that much. Given the difficulty I've had trying to figure out how to implement this, I think I may be better off coming at it from another angle in any case. /~\ 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: SLIP coexisting with serial data?
>> I was looking at improving if_sl.c to support encapsulating "normal" >> serial data on the SLIP's tty as packets, [...] > I've encountered that on a serial protocol in my Arduino work. It > worked quite well i have to say. It worked due to a packet starting > with an unique byte. [...] > I don't know SLIP anymore by heart but maybe you could `invent'/use > an IP# of 127.0.0.1 as a special case (or 0.0.0.0) to carry the > key/terminal stuff. Oh, that's not the problem. This is where the v6 patches have relevance: carrying v6 involves inventing a way to tag packets with types; I used one of them for v6, and it would be easy to use another for serial data. The difficulty is in the kernel: SLIP works by switching line disciplines, which makes it difficult to get normal output processing to happen - and what I want is for that to happen and then run the result through if_sl.c before sending it to the real hardware. In the light of morning, I'm not sure this will get me what I want even if I make it work. I need to think about it more /~\ 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: SLIP coexisting with serial data?
> It seems you want to have a console (in the wscons sense) Well, no; I want a serial console, not a wscons console. > which is *not* associated with a serial port, and then bind that to a > logical serial channel on a SLIP instance which is instead bound to a > serial port. That would be one way to get the effect I want. Another way - the one that I'm pursuing now - is to hack on the serial line driver for the relevant console hardware to, loosely put, import SLIP into it. Instead of having two faces, a tty device face to the kernel and a driver face to the hardware, I'm planning on giving it three: a tty device and a network interface to the kernel and a driver face to the hardware. The userland schemes went out the window when I realized I really wanted both tty and network device to be usable pre-single-user. /~\ 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: SLIP coexisting with serial data?
> I wonder if you would need this kind of console even for ddb work. Well, I want it to work for direct kernel<->user interaction; ddb is an example of that, but so are pre-single-user things such as userconf and printing autoconf output. > If you need console for ddb, things get messy. Indeed they do. As I mentioned in another message I sent moments ago, I'm currently looking at, basically, importing SLIP into the relevant serial-port driver, so that it becomes not just a tty and console driver, but a tty, console, and network interface driver. /~\ 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: acpivga(4) v. MI display controls
>> The task is not trivial. On modern x86, practically *everything* >> that attachs has an ACPI counterpart. In a way we are thinking this >> backwards: the attachment should perhaps be done via ACPI that has >> information about the "natural" device tree ACPI may be the source of the information, but that doesn't mean it has to be how the autoconf tree is constructed. Compare and contrast with how NetBSD/sparc uses the OF (or is it OBP? I'm not sure) device tree to drive autoconf, but doesn't have a device node corresponding to OF that everything attaches under; it just uses the OF tree as the source of the data about what exists where. (Well, much of it; autoconf doesn't totally mirror OF, eg, in SCSI device attachment.) > This should be solved once and for all, for all acpi(4) and for all > pci(4), isa(4), ... Otherwise we end up with god-awful mess. Has anyone tried handling it by giving devices multiple parents? This would clean up some other things, such as wscons (there arguably ought to be something which is parented to both the wsdisplay and the wskbd). I have no idea how much hair it would introduce, though. /~\ 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: acpivga(4) v. MI display controls
> This is the other main difference to OF: on ports using OF, it is > always available. ACPI on i386 is not (yet). It's not quite as simple as "ports using OF" and "ports not using OF". For example, while I have personal experience with only the one unit, http://www.netbsd.org/ports/sparc/javastation.html#mrcoffe implies fairly strongly that some JavaStation-1s have OB and others have OF. And I _think_ some of the older machines supported (at least last I knew!) by NetBSD/sparc are old enough to have neither, though I'd have to dig out examples and try them to be sure - I may be confusing Sun-3s with Sun-4s. /~\ 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: mlock() issues
> proc.curproc.rlimit.memorylocked.soft = 697976149 > With all of the above set, for some reason it's not possible to lock > more than 666MB. Well, 697976149 bytes is 665.6419+ MB, so it sounds to me as though it's doing exactly what it should be. Unless you're a disk manufacturer, in which case 697976149 bytes is 697+ "MB", but I suspect you're locking 666 MB, not 666 "MB". /~\ 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: pmap_extract(9) (was Re: xmd(4) (Re: XIP))
> The only right way to retrieve P->V translation is to lookup from > vm_map (== the fault handler). What about setting up DMA on machines whose DMA uses physical addresses? Or does the DMA code get an exception to this rule? I also suspect debugging may well be a non-ignorable use case, though I could also be wrong about that. /~\ 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: mutexes, locks and so on...
>> Over 15 years ago NetBSD had a possibility to take everyone into >> account [...] > So what you are arguing is that MI needn't be so much MI anymore, and > that supporting anything more than mainstream today is more to be > considered a lucky accident than a desired goal? Looks to me like pretty much exactly what pooka was saying. > Oh well! I guess I should go away now. And me, and everyone else running anything but x86_64 (and, maybe, i386; I don't know whether that's sufficiently modern to count). Compilers that page themselves to death unless given over twice the RAM a uV2 maxes out at. Decisions driven by "a megabyte of disk costs what, $0.8?". Now this. bqt, wanna start a fork? Looks as though NetBSD no longer supports most of the architectures it used to. /~\ 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: mutexes, locks and so on...
> It is not about mainstream. Please tell me one architecture that has > been created in the last 10 years, supports at least 32bit address > space, virtual memory and doesn't support either CAS or LL/SC. What's that got to do with it? NetBSD used to be about proper separation between MI and MD so that multiple architectures can be accommodated. Even if that meant a lot of hard thinking to find the right line between MI and MD to take advantage of things like the MP-ready queue instructions bqt pointed out the VAX has. This now makes it appear it now is about lazy coding so that the "mainstream" architecture can be supported and other arches can be kinda-mostly supported as long as they're close enough to x86_6^Wthe "mainstream" one. /~\ 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: mutexes, locks and so on...
> Exactly! And I would like to emphasize that this has nothing to do > with breaking of MI and MD abstraction or x86-centric view. Yes, I imagine you would. But it's still false. > Decision was to provide CAS abstraction [sic!] as a primitive for MI, > by the MD land - in a same way, like we have copy(9), fetch(9), > store(9) or many other means, just in this case MI asks MD to ensure > atomicity. It was relevant to make a break-through for better SMP > support, since it is an essential primitive used for synchronisation. It is not. It may be essential to your preferred implementation, but it is not essential to synchronization. (Nor pretty much anything else, actually. Not even if CAS is the operation you want for some reason; CAS can be implemented in terms of other primitives.) The correct MI abstraction here is "sychronization". (Or "atomic queue", or "mutext", or whatever.) CAS, if used, should be a part of the implementation. It may even be shared among MD implementations for which it is appropriate. But to impose it on arches which don't have it but which do have perfectly good synchronziation (or whatever) primitives is to draw the MI/MD break at the wrong place, to push MD aspects into supposedly-MI code, just as much as building code based on INSQTI/REMQHI and then requiring everything not supporting atomic DLL ops to implement those somehow would be. > What Johnny apparently suggests is to revisit mutex(9) interface, > which is known to work very well, and optimise it for VAX. Well, I > hope we do not design MI code to be focused on VAX. Why not? You don't mind designing it in (other) MD ways. > If we do, then perhaps I picked the wrong project to join.. :) One of us certainly did. /~\ 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: mutexes, locks and so on...
> Hadn't it been much nicer of we just had the mutex and lock > abstraction, and left the whole implementation to each MD part? Exactly. Consider this hypothetical: x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code notices this and defines all the higher-level primitives (if that's not too much of an oxymoron) in terms of CAS(). ppc, arm, all the arches sufficiently "modern" to have CAS, likewise. Arches without a sufficiently general CAS[%] do not define ATOMIC_OPS_USE_CAS and provides their own implementations of mutexes, spinlocks, whatever. That seems to me like a mostly sane way to do it. If I can come up with it in thirty seconds, it seems likely anyone capable of doing such overhauls could come up with it. Instead, all arches must implement a fully-general CAS. Seems to me like a lose. [%] It occurs to me, the VAX's BBSSI and BBCCI _are_ CAS, just restricted to a one-bit-wide operand (and with the data-to-swap-in specified by choice of instruction rather than an operand). /~\ 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: mutexes, locks and so on...
> Already wrote about reasoning in other reply to mouse (keywords: no > code duplication, better design), so wont repeat myself. Except you appear to think that the only options are the current state and each arch totally doing its own thing. There are places other than those two to draw the dividing line. Indeed, there are semi-MI implementations possible, such as the one I sketched in a message I sent just minutes ago, allowing arches that can to share code while not imposing an inappropriate paradigm on those that don't fit the mold. Somewhat like the way the various 68k ports share nontrivial amounts of code through sys/arch/x68k (and similar things in userland) and similarly for MIPS and SH3 and possibly others I haven't noticed. /~\ 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: mutexes, locks and so on...
Just a note to avoid having incorrect information in the archives without a correction. I wrote: > [%] It occurs to me, the VAX's BBSSI and BBCCI _are_ CAS, just > restricted to a one-bit-wide operand (and with the data-to-swap-in > specified by choice of instruction rather than an operand). This is false. CAS, as the term is normally used, turns out to be not the compare-and-swap the acronym expands to but compare-and-conditionally-swap. However, BBSSI and BBCCI always perform the write. /~\ 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: CVS commit: src/sys/arch/powerpc/oea
>>> Every header file should include the things it requires to compile.
I've long felt this way: that, except for a very few examples like
that are defined to depend on context, the order of
#includes should not matter. In particular, if multiple files must be
included, any of them may come first - so any file that generates
errors if it's included first needs fixing. (Well, unless it's an
internal file, one that shouldn't be included directly.)
I've got numerous fixes to 4.0.1 for such issues, in case anyone thinks
it's worth applying this stance to 4.x.
> [...] just forward declarations of the structs.
> (this is, btw, one of the reasons to avoid silly typedefs)
I'm not sure what typedefs have to do with it. typedeffing a name to
an incomplete ("forward") struct type works just fine:
struct foo;
typedef struct foo FOO;
(You can't do anything with a FOO without completing the struct type,
but you can work with pointers to 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: CVS commit: src/sys/arch/powerpc/oea
>> I've long felt this way: that, except for a very few examples like >> that are defined to depend on context, the order of >> #includes should not matter. In particular, if multiple files must >> be included, any of them may come first - so any file that generates >> errors if it's included first needs fixing. > assert.h is the *only* header that is not supposed to be idempotent. > Pretty much anything else should be classified as bug. I'm not talking about idempotency. Idempotency is the question of whether #include #include is operationally equivalent to #include But what I'm talking about is whether #include #include and #include #include are operationally equivalent. > Another item is that too many of our headers depend on non-standard > compliant types polluting the namespace. This is another issue I have with our include files, but it's significantly more work to fix, so I've been working around it rather than fixing it right. (It's also not entirely clear what the right fix is when more than two levels of software supplier are involved.) > Nothing installed in /usr/include should depend on u_char for > example. Well...ideally. But there's a big difference between (say) depending on u_char and depending on u_char. (I'm not happy about either, but substantially less happy about the former.) >> struct foo; >> typedef struct foo FOO; > Problem is that this requires a guard for the typedef if FOO is > supposed to be defined by multiple files. True. Most of the cases I've seen for this push the incomplete struct declaration and the typedef into a separate file, wrap it with an idempotency guard, and then include that from files that need the struct and/or type. I've seen a very few cases where this hasn't been done and I think none at all where it couldn't be done if the relevant software authors cared to bother. /~\ 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: misuse of pathnames in rump (and portalfs?)
> However, I discovered today that rumpfs's VOP_LOOKUP implementation > relies on being able to access not just the name to be looked up, but > also the rest of the pathname namei is working on, specifically > including the parts that have already been translated. "Eww." The rest of the path to the right, that makes some sense (though I'd prefer the filesystem handle it using vnodes for the intermediate directories). The rest of the path to the left, that makes no sense. Not to me. > When I asked pooka for clarification, I got back an assertion that > portalfs depends on this behavior so I should rethink the namei > design to support it. If so, I believe portalfs is critically broken and should be pulled until it's fixed. > (1) does anyone think that a correct namei design should provide the > namei pathname scratch space to the FS for its inspection during > lookup? Not me. > (2) does anyone think that a correct namei design should provide a > correct canonicalized full pathname for its inspection during lookup? Not me. > (Note that this is free -- it would require splicing a getcwd into > every namei call.) _Not_ free, I assume you mean? > (3) Does anyone object if, as a way forward, I add an extra argument > const char *partialpath to VOP_LOOKUP to provide the string that rump > wants, until rump is fixed, and then revert it? Well...I don't like it; such "temporary" hacks have a way of becoming rather less temporary than they should. Personally I think the right fix is to fix the interface and, if this breaks rump, and let it stay broken until someone fixes it to not abuse the interface. But I'm hardly the arbiter of such things. > (4) vermilion. Dead jackal brown. /~\ 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: misuse of pathnames in rump (and portalfs?)
>>> (Note that this is free -- it would require splicing a getcwd into >>> every namei call.) >> _Not_ free, I assume you mean? > er right, silly editor... :-/ :-þ I've had that happen to me often enough. > Anyway, it looks as if it's not needed. Just as well. It has (since) occurred to me that it won't even work, unless you're willing to accept a regression in that it will totally break namei when the current directory no longer has any name. /~\ 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: misuse of pathnames in rump (and portalfs?)
> Right. But if you want a guaranteed absolute path you should be able > to do it by calling getcwd first. Only if you accept breakage if the current directory no longer has any name. Of course, if you consider that acceptable, then fine. I don't, not for something as central as namei (though this looks as though you may be talking about only certain filesystems, in which case it may be acceptable). /~\ 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: radix tree implementation for quota ?
> If you have issues with a power of 2 hash table size, you do not have > a good hash function in first place. Almost by definition. > With a good hash function, using a non power of 2 size just tends to > be slower. Indeed - other things being equal. Which they often aren't. I think the point of a prime table size is that with a hash key that's an integral type, as here, then you can often use a prime table size and get decent reults from the identity hash function - or, to think of it another way, use value%size as your hash function and use the identity mapping from hash values to table buckets. A prime hash table size gives about as good hashing under this sort of scheme as anything, for most key distributions. Yes, reduction modulo a prime is generally a substantially slower operation than masking off all but the last N bits. However, if it's faster than the hash function you were going to use before doing the masking, which is not infrequently the case, it's an overall win. /~\ 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: radix tree implementation for quota ?
> [...] but as I understand it, the [NFS] server implements its own > limits, not the client, which is as it should be. The server should enforce limits if it is configured to have them, yes. But the only reason I can see why the client shouldn't also be able to put quotas on an NFS-mounted filesystem is implementation laziness. (Justfied laziness, perhaps; "laziness" carries a somewhat pejorative implication that may be not entirely deserved here, but I'm having trouble coming up with a better word.) /~\ 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: radix tree implementation for quota ?
> The prime number hash always looks good for most simple sequences.
> It looks extremely bad for other choices like {p, 2p, 3p, 4p, ...}.
Indeed.
> But for semi-random input, the simple prime hash can be a very bad
> hash function.
What's "semi-random" here? For random input, that is, input
uncorrelated with anything else, all hash functions are equally good,
so the simplest/fastest is best. But input is almost never truly
random. (In this case, for example, it is heavily weighted towards
numbers near zero.)
Without any real data on what UID distribution looks like in practice,
we're all speculating in a vacuum here.
> If the keys are controlled by a third party, it is very easy to
> degrade the performance to a linear list.
Sure, but that's not a useful remark. It's equally true of (n*K)>>32,
or for that matter any other easily invertible hash function. If the
bucket count is small enough to make guessing feasible for the
attacker, it's true of any hash function cheap enough to be useful as a
hash function.
/~\ 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: ioctl(2) vs sys/ioctl.h
>> int ioctl(int, unsigned long, ...); > Most of our ioctl's take pointer arguments. Some streams ioctls > though take int arguments (ioctl(fd, I_FLUSH, FLUSHR) for example) > and using void * as the argument would not compile cleanly. Must FLUSHR (to continue your example) be defined as an int value? Obviously there can be ABI issues, but they can be worked around the same way you work around other compat ABI issues - or ignored, on arches where ints and void *s are passed sufficiently compatibly. Or perhaps ioctl could turn into something else after #including the file that defines I_FLUSH and/or FLUSHR? I'm just brainstorming possible ways to avoid inflicting a varargs declaration on all users of ioctl. I don't know whether there are any issues which might break the above ideas - assuming anyone besides me cares, that is. /~\ 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
