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.
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
