On Mar 1, 2015, at 5:33, Sulev-Madis Silber (ketas) <madis...@hot.ee> wrote:

> Hello.
> First, I would be happy to have JSON and XML output about filesystems,
> users, routes... but I don't like how it makes code of df, w, netstat
> hard to read/maintain and often broken.
> I don't think it would be good to continue with this. Maybe the effort
> should be put to creating new layer/library and then something on top of
> it that actually outputs JSON and XML.
> Or, if that's too difficult... maybe just regular df/w/netstat could be
> copied to somewhere else and made code libxo-output-only. And original
> df/w/netstat changes reverted and left alone.
> Then, maybe later, df/w/netstat/... could be updated to this new
> layer/library. Or maybe this should be just left as it is.
> That would mean having two netstat's in system, which could be both good
> (separation) and bad (maintaining).
> Just some ideas... I don't know how to solve this issue fully. I'm also
> not likely the one who would write code for all this. Hell, those aren't
> even all my ideas here. I just worry that system drop-in xo-zation is
> bad for overall health of base.
> Oh and, it makes rescue larger and more complex, too? On that, there was
> suggestion to maybe create separate "first aid kit" and "emergency room"
> types of system rescue utils/methods.

Hi Sulev,
        Could you please cite instances where things were broken with 
converting utilities (netstat seems to be a sticking point — do you have data 
to support this?) over to libxo? The big problem (I think) is lack of tests 
with these utilities to ensure that output doesn’t break unknowingly.
        I definitely see the wisdom in having /rescue be de-libxoified. It 
seems to go against the purpose of having a small “rescue image” binary — 
whereas the bsdxml integration into geom(3)/geom(4) is a necessary evil.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to