Re: Status of ext3fs in NetBSD?
On Wed, Oct 23, 2013 at 01:03:16PM -0400, Jeff Read wrote: I was wondering if anyone was still actively working on ext3fs support in NetBSD. I noticed it listed in the projects page and wanted to synchronize my own extNfs efforts with anything currently ongoing. To my knowledge nobody is currently working on it. -- David A. Holland dholl...@netbsd.org
Re: Moving Lua source codes
Am 21.10.13 21:22, schrieb Alexander Nasonov: Marc Balmer wrote: Yes, this is an issue. Dunno if we need a 'kluac' or so, at the moment I'd say loading code from source form is ok. Supporting binary chunks is more challenging because binary format can change completely in a new Lua version. Source code is more stable, there are often small changes in the language too (like new keywords) but I'd say they are manageable. And then the language only changes very slowly, the developers are very careful not to change the language in drastic ways (and after 20 years I hope one can assume some stability in the language, anyways).
Re: Moving Lua source codes
Am 21.10.13 07:57, schrieb Artem Falcon: [...] Doing w/o a diff, i don't have a sane mail environment now to send it inline. There's few more things. First: you forgot to add MODULE_CLASS_LUA_BINDING to a sys/sys/module.h. FWIW, I removed the MODULE_CLASS_LUA_BINDING and use the existing MODULE_CLASS_MISC for Lua bindings. require 'foo' will look for a kernel module with the name luafoo and load it, if existing. It is the up to luafoo to register whatever it has to offer. In the unlike case that luafoo was something else than a Lua binding, it would be loaded, but provide no functionality. That is the only side-effect I can think of right now. So I think require can not be abused to load arbitrary modules, since they must be prefixed by lua.
Re: Lua in-kernel (lbuf library)
Am 21.10.13 00:05, schrieb Christoph Badura: On Tue, Oct 15, 2013 at 06:01:29PM -0300, Lourival Vieira Neto wrote: Also, having to switch mentally between zero-based arrays in the kernel C code and 1-based arrays in the Lua code make my head ache. It's something that doesn't bug me so much.. But, if necessary it could be changed to 0-based in this userdata. When you create your own data structures, I guess it is a wash. You have to adjust +/-1 in infrequent circumstances in either scenario. But in this case you are creating a special purpose language that operates in universe of zero-based array. And that's not only the kernel code. Every Internet protocol specification that I remember is using zero-based indexing. For someone dealing with both sides (the world and your lua library), it makes the difference between constantly having to be alert to remember to do the offset adjustment. That is a lot more mental work for anyone working with this library. If you use 1-based indices talking to protocol people will be funny too: ``Anyone know why the flags in byte 6 of this packet are funny?'' ``Sure, that's most likely because the flags are in byte 5.'' I think it is worth thinking hard about this. From a cursory reading of the Wireshark Lua API, it seems to me they are using 0-based indices too. It probably depends whether you are access a Lua table (where you'd expect 1-based) or if you are accessin an in-kernel datastructure that is not strictly a Lua table. If a Lua function is to mimick an existing C function, it might be better indeed to use 0-based access, to not confuse developers who are probably familiar with the corresponding C function. As this is mostly a matter of taste/source of confusion, it should be documented. A man page for a Lua function that offers the same or similar functionality as a C function should state whether it's 0-based or 1-based, imo. [...]
Re: Lua in-kernel (lbuf library)
Am 19.10.13 00:51, schrieb John Nemeth: } kern.lua.autoload is a safety barrier. One may wish not allow any lua kernel } script to load any given lua kernel module. The lua(4) implementers can certainly do this if they want. However, module_autoload() won't be looking at this flag and will continue to refuse to autoload any module that has the noautoload flag set. Also, there is the kern.module.autoload sysctl that can prevent any module from autoloading. And I think that is a good thing. If kern.module.autoload is used to prevent module autoloading, then lua(4) must not be a way to circumvent this. For clarification: The kern.lua.autoload sysctl merely controls whether lua(4) *tries* to autload a module when it encounters the require statement. If it is set to false, it will not try it.
How to hot swap an SCA SCSI disk with NetBSD
What is the specific sequence of NetBSD commands to execute in order to successfully hot swap an SCA SCSI drive? Obviously, umount(8), maybe scsictl(8) for stopping the disk ... Please specifically discuss issues relating to differing disklabels, both on-disk and in-kernel. Our documentation seems to lack this procedure. Erik f...@netbsd.org
Re: How to hot swap an SCA SCSI disk with NetBSD
What is the specific sequence of NetBSD commands to execute in order to succ$ It depends on the hardware. If the hardware is hot-swap, then I'd just unmount (or whatever), scsictl detach, unplug, replug, scsictl scan, remount (or whatever). If the hardware is not hot-swap, it's iffier; you pretty much have to guarantee that the bus is quiet during unplug and replug. Connecting or disconnecting a device while another device is wiggling the lines is a recipe for errors. Personally I usually L1-A the machine to ddb to do that, unless it's not the primary SCSI bus, in which case I can often just unmount and detach everything. The sequence is the same, except that whatever you do for bus quiescing applies around the unplug and replug operations. Of course, if the hardware is not hot-plug, there is some chance that hot-plugging could damage something. Personally, I consider that risk small enough to ignore in most cases - all I've run into so far - but it's something to at least keep in mind. Please specifically discuss issues relating to differing disklabels, both on$ I have never needed to pay any specific attention to this; presumably the device-tree data structure destruction and recreation implicit in scsictl detach and scsictl scan handles it. If I really need to poke disklabels, I usually use sunlabel (or bsdlabel when not using Sun labels), which has a command to set the kernel's live label as well as a command to write the label to the drive. (Indeed, in a few cases I've set the kernel label and specifically _not_ written it to the disk, when I'm doing some kind of transient hackery.) And, of course, I don't know how this may have changed in post-5.x NetBSD; you don't say which version(s) you care about. But I think everything I wrote above is basically the same all the way from 1.4T through 5.x, so it seems to me it's _probably_ the same post-5.x. /~\ 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
