Porting dmesg

[Andrew van der Stock]

Hi folks,

I've been spending a bit of time working on bringing up my Minix skills before doing some really crazy. I felt it was important to do something useful. I miss the dmesg command most of all, sort I "ported" it, but obviously, the MIB KERN_MSGBUF syscall doesn't currently support it. So I made some small progress towards getting dmesg to run by getting ready to add KERN_MSGBUF as a supported MIB value, which when you look through NetBSD sources is non-trivial. 

Current status:

minx# dmesg

dmesg: can't get msgbuf: No such file or directory

So before I go hacking away at the MIB source, I would like to obtain advice from the Minix elders.

The NetBSD code for this is in sys/kern/subr_log.c, which is a LOT of additional stuff that is probably why dmesg is not currently already in Minix. So before I go hacking in dmesg and therefore minix kernel support for returning the contents of the boot messages, I need to know what would be considered success? Personally, I think I know the answer already - it should be able to return the boot messages, but I don't want to simply hack at it and no provide the -M and -N switches, nor really advance the status of message logging in the early kernel. 

In NetBSD, kernel message buf storage is backed by /var/run/dmesg.boot, but in Minix it is /var/log/messages. Which should I use? It's easiest to update the man page, I suppose, but if we are aiming for NetBSD atop Minix as a kernel, then the NetBSD paths are the appropriate ones to minimise changes to dmesg itself (which currently has zero hacks applied). By doing it right, and moving the path, there will be an obsolete path but it does mean any future merges from NetBSD are cleaner. 

NetBSD uses mutexes as a spinlock. What primitives should I be using to ensure SMP-compatibility within the Minix kernel, knowing full well that atm, Minix SMP support is bit rotted? As NONE of the devices I own is single core, I think we need to address this before really getting going. 

There is a bunch of stuff in the sys/kern/sub_log.c, including signals that I am not sure the server which contains this code will have any use for or even process. Is there a better way in Minix to cover off that, or should I only concentrate on sysctl_msgbuf()?

thanks,

Andrew

[Jean-Baptiste Boric]

Hi,

I'm no elder, but I do know my way around the source tree.

While MINIX now uses the NetBSD userland, the MINIX service layer and micro-kernel are homegrown. That means in practice there is little to no NetBSD code in the service layer and the micro-kernel. The lowest layers of the system libraries and libc (mostly what would invoke NetBSD syscalls) are rewritten to match the MINIX multi-server architecture API/ABI instead.

That means the NetBSD kernel sources are (almost) not used in MINIX 3 and we'd rather not do sweeping changes inside it because one day we might successfully import rump.

As for SMP, I recall that services are either single-threaded or use user-space worker threads with libmthread. It seems that the MIB service is single-threaded, which is consistent with my expectation that it is not a performance-critical service.