Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Mar 2015 12:43:42 -0800
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        "Sulev-Madis Silber (ketas)" <madis555@hot.ee>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Massive libxo-zation that breaks everything
Message-ID:  <EF533774-56B8-418A-987B-D2BB691CBD7C@gmail.com>
In-Reply-To: <54F31510.7050607@hot.ee>
References:  <54F31510.7050607@hot.ee>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_45536404-150D-48A2-8D02-91C80A38318C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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

> Hello.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Then, maybe later, df/w/netstat/... could be updated to this new
> layer/library. Or maybe this should be just left as it is.
>=20
> That would mean having two netstat's in system, which could be both =
good
> (separation) and bad (maintaining).
>=20
> 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.
>=20
> 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 =97 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=92t break =
unknowingly.
	I definitely see the wisdom in having /rescue be de-libxoified. =
It seems to go against the purpose of having a small =93rescue image=94 =
binary =97 whereas the bsdxml integration into geom(3)/geom(4) is a =
necessary evil.
Thanks!

--Apple-Mail=_45536404-150D-48A2-8D02-91C80A38318C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJU83n+AAoJEMZr5QU6S73eexYH/1MFAqXiTyCYqTU6y7bYj9WI
cTweLVA9tD/IPgjfcybcx8E1IX7tiBPsUpFd19knGQXuEIcTJYKu/amceaouixIe
p8trz58rpfoIc8lAUsyDZ41nUzTcREHpiqM5SfURoHpLQemwjfrIbOLG8kLBVKPc
DVTigpRNjSTBNCBtQ842qc15A27RZk75HHGltMKoLtFIJrHS9gFiIV3HUIkLeSs6
RbwxJAkBW365egC6JAby6O/ItmER63PSv4pjU/gbWytaYebKMZwBOsH7a1b19ajs
0GvM1mib5r9iRiCyULE9qa80Pr3tOmfs3keyUYjHTPgTP7tHMnCxsDedjcawOks=
=i689
-----END PGP SIGNATURE-----

--Apple-Mail=_45536404-150D-48A2-8D02-91C80A38318C--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EF533774-56B8-418A-987B-D2BB691CBD7C>