Date: Fri, 13 Jul 2007 13:16:00 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John Baldwin <jhb@freebsd.org> Cc: Rui Paulo <rpaulo@fnop.net>, "Constantine A. Murenin" <cnst@freebsd.org>, Shteryana Shopova <syrinx@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <80513.1184332560@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 13 Jul 2007 07:40:15 -0400." <200707130740.17680.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200707130740.17680.jhb@freebsd.org>, John Baldwin writes: >ifconfig doesn't use strings from sysctl. It uses a more sophisticated >interface with data structures, etc. If you wanted to add a standard RAID >monitoring interface, then I would add ioctl's for different RAID operations >along with a set of generic RAID structures [...] I wouldn't. The amount of time and code it takes to encapsulate instructions in binary structures, and then unpack and validate those same structures is utterly wasted for complex interfaces like that. The reason why we started out on the struct+bitmap method, was that the structs were copies of the hardware or kernel structures, so there were no work involved in receiving and sending them from the kernel. But we are increasingly using abstract representations for reasons of portability and multi-everything-support, and now we end up having to treat the binary structures and bitmaps as very complex communication protocols and look for all the sorts of evil you can have in binary data (overruns, underruns etc etc.) For complex low-frequency interfaces, like RAID management, I would (and have: see GEOM) simply send text strings to the kernel and deal with all the parsing and validation there. Part of the reason for this is that their very complex nature makes the struct representation particularly unwieldy, whereas the good old command line metaphor manages to capture complex data forms in a readable and easily parseable format: find . -type file -name '*.c -print >Strings are a horrible data interface. The stuff I work on needs to send >e-mails that are more like: > >volume X on controller Y is degraded >the following disks(s) need to be replaced: drive 5 (enclosure 1, slot 2), > drive 7 (enclosure 1, slot 4) > >To do that sanely, I need to have access to data structures, not just >arbitrary strings from a sysctl. I thought a lot about that with GEOM, and that's why the output from the kernel is highly structured, but free form (ie: XML). Overall I think the assymetric API GEOM got, and in a lighter degree nmount, are the way forward. The age of the intricate struct + bitmap is a cul-de-sac, which leads to unreadable and buggy code to encapsulate and decode a binary format at the syscall interface, which nobody really cares about. ifconfig is a primary candidate for being rototilled like this: if you compare the length of the average ifconfig argument list to the number of structures and bitflags manipulated, it will soon be seen that shipping argv[] to the kernel and only parsing once would be much more economical and less bugprone. Move with the times people... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80513.1184332560>