Re: genfs_node lock
Never mind. It protects some on-memory data which I don't know. (Why do I lock lots of things to read read-only ROM data? I wish VFS/BIO were written in Haskell...)
Re: Please do not yell at people for trying to help you.
Matt, On 2010-11-13 04:17, Matt Thomas wrote: The VAX now has a fast non-MP emulation of atomic_cas so that should be less of an issue. I looked at this code, as well as your musings about the design. Did you miss one step in there, or did I miss something? I thought that we needed to reset the address pointing location on all traps/exceptions, but we don't seem to be. So unless an interrupt actually calls the CAS function, the CAS will happily run to completion no matter how many intervening interrupt, exceptions and context switches occur. I'm trying to see if this can be a problem, but I'm not sure. But based on your comments in your design, I seem to read that the idea was that the address pointer should be reset on every exception. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip - B. Idol
Re: Please do not yell at people for trying to help you.
On Nov 20, 2010, at 12:25 AM, Johnny Billquist wrote: Matt, On 2010-11-13 04:17, Matt Thomas wrote: The VAX now has a fast non-MP emulation of atomic_cas so that should be less of an issue. I looked at this code, as well as your musings about the design. Did you miss one step in there, or did I miss something? I think the latter. I thought that we needed to reset the address pointing location on all traps/exceptions, but we don't seem to be. So unless an interrupt actually calls the CAS function, the CAS will happily run to completion no matter how many intervening interrupt, exceptions and context switches occur. Not really. We only need to reset the memory address if another CAS interrupts the current CAS if we make the simplifying assumption that writes to the memory address will only be done via a CAS operation. I'm trying to see if this can be a problem, but I'm not sure. But based on your comments in your design, I seem to read that the idea was that the address pointer should be reset on every exception. That would be true if we have naked writes to CAS locations but once you switch to using CAS, you use CAS for all writes. So the assumption above saves a little work and makes the RAS have very little overhead.
Re: module.prop rename
On Apr 12, 5:11pm, David Holland wrote: } On Fri, Nov 19, 2010 at 12:33:00AM -0800, John Nemeth wrote: }.prop is short for proplib or property list. It also made } coding easier as s/.kmod/.prop/ doesn't change the length of the path. } Anyways, I have received several private requests to change the name to } module.plist. After thinking about it, I believe this to be a good } idea. It seems that .plist is a somewhat standard extension for a file } that contains a property list (see Wikipedia). } } I don't care one way or the other about the name but I have a } different suggestion: since, nominally, serialized proplib files } aren't supposed to be hand-edited, wouldn't it make more sense to That doesn't mean that people can't hand-edit them. Also, they can be generated using 'modload -p'. } embed the property info in the module file itself? That may or may not make more sense, but it would require a lot more work (i.e. inventing a tool to extract them, edit them, and insert them; and modifying the module loading code to extract them). I have very little interest in doing that work at this time. }-- End of excerpt from David Holland
Re: module.prop rename
On Sat, Nov 20, 2010 at 07:50:03PM -0800, John Nemeth wrote: } embed the property info in the module file itself? That may or may not make more sense, but it would require a lot more work (i.e. inventing a tool to extract them, edit them, and insert them; and modifying the module loading code to extract them). I have very little interest in doing that work at this time. Fair enough. -- David A. Holland dholl...@netbsd.org
