On Mar 1, 2015, at 5:33, Sulev-Madis Silber (ketas) <madis555_at_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!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC