Date: Mon, 9 Oct 2017 17:37:05 -0600 From: Warner Losh <wlosh@bsdimp.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@freebsd.org, Warner Losh <imp@bsdimp.com>, Ian Lepore <ian@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: deorbiting /usr/lib/libstand.a, moving to sysboot Message-ID: <01205326-3312-47A1-B2B8-D8C7976F1DFD@bsdimp.com> In-Reply-To: <1838629.1fOj0Hxk8Q@ralph.baldwin.cx> References: <CANCZdfrvD04cL3A1J3nKZ2uFNNkOrcVnMvobdoyXkRGx8VK8Vg@mail.gmail.com> <1507565759.77958.7.camel@freebsd.org> <CANCZdfp3o7ymPY=NxSa2Cs4-wM0PvLq7=2aW8ud8S0EhC3%2B-4g@mail.gmail.com> <1838629.1fOj0Hxk8Q@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2017, at 5:19 PM, John Baldwin <jhb@FreeBSD.org> wrote: >=20 > On Monday, October 09, 2017 10:21:53 AM Warner Losh wrote: >> On Mon, Oct 9, 2017 at 10:15 AM, Ian Lepore <ian@freebsd.org> wrote: >>=20 >>> On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote: >>>> On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore <ian@freebsd.org> = wrote: >>>>=20 >>>>>=20 >>>>> On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote: >>>>>>=20 >>>>>> On 9 Oct 2017, at 07:45, Warner Losh <imp@bsdimp.com> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h. >>> These >>>>> are >>>>>>=20 >>>>>>>=20 >>>>>>> really parts of the boot loader with an unstable API and = shouldn't >>> be >>>>>>> installed into the system. It's really a private library to the >>> boot >>>>> loader. >>>>>>=20 >>>>>> Though I completely agree with this, I am still interested in the >>>>>> historical reasons for separating out this library for general >>> userland >>>>>> consumption. Were there any other parts of world that happened = to >>> use >>>>>> libstand? >>>>>>=20 >>>>>> -Dimitry >>>>>>=20 >>>>> There are out-of-tree users of libstand. Perhaps not many, but a >>>>> couple times after doing something to libstand I've received = emails >>>>> from people that thanked me for the enhancement and mentioned some = non- >>>>> loader(8) use of the lib in passing. (Unfortunately, I can't find = any >>>>> of those mails now, they were from 2-3 years ago.) >>>>>=20 >>>> They can email me and I'll help them convert over... :) >>>>=20 >>>> Warner >>>=20 >>> Actually, I got distracted, then came back and hit Send too soon. I >>> meant to ask "Will the library still be accessible to out of tree >>> users?", so that adjusting to the change will amount to fixing some >>> build breakage to adjust to a new location? >>>=20 >>=20 >> The proposal is to take it 100% internal and officially not support = its use >> outside the loader. >>=20 >> It's open source, so if you really want to use it, you can with some >> effort. If there's one or two people, they can adjust. If there's = lots, >> then I can revisit the proposal. It would help to know who they were = and >> what, exactly, they used it for. >=20 > Note that one wrinkle is that libstand pulls in source bits from libc. > Historically it's been possible to checkout just sys/ and build = sys/boot if > you had a matching world because libstand would be installed. This = will > now require a full world checkout. That's probably not the end of the = world > (and it is debatable if 'boot' even belongs in sys/ vs being a = separate > top-level dir in the source tree). In general we try to make sys/ = (for > the kernel) be self-contained and this would kind of break that, = though I > think I'd be happy moving boot out of sys/ altogether to restore that > convention. Except that=E2=80=99s not been true for a long time=E2=80=A6. libstand32 pulls from lib/libstand, or did until recently. userboot/libstand likewise. sys/boot needs both to build. It=E2=80=99s historically been under sys = since around V32 if my sleuthing is right, though there=E2=80=99s been = expcetions (cf src/mdec in BSDs as late as 4.4BSD). v7 had them in = /usr/mdec as well as src/cmd/standalone, so hoisting them a level would = represent a return to the past. Though we=E2=80=99ve hopelessly mixed up = the clean separation of low-level =E2=80=98boot1=E2=80=99 like loaders = that knew just enough to find boot2 on the disk programs with our all = singing, all dancing /boot/loader (which is more or less analogous to = src/cmd/standalone, though at the time things weren=E2=80=99t packages = together for size reasons). Not sure that it=E2=80=99s worth sorting = that last stuff out at this late date though=E2=80=A6 That=E2=80=99s a long way of saying =E2=80=9CI=E2=80=99d support moving = it to src/$(result-of-bikeshed sys/boot)=E2=80=9D but that=E2=80=99s not = what I=E2=80=99m doing today. Warner P.S. Since there was no pushback, and evidence of a ton of pent up = demand, I=E2=80=99ve gone ahead and pulled the trigger on the move. --Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A 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 iQIcBAEBCgAGBQJZ3AghAAoJEGwc0Sh9sBEAr08P/RQJ4wxGvWZ+ZrgyxTvq70vt qA36l3MDc2ySPCtQiDsOIYXW0bgrUDcY1FZxpCzWq+pLrb4aCPXVJzIGKgyXPd63 w5mmf89QsNG+5rCCvwd2FIDeluLa9qVMQUSW1U3dIGUa+60GeuZHe/5g55fFZ34t TSc+vgYkoeRNjIzupt71PQUWfMZNcRKRWuLv3AR4VXrdh5nWrPmAtLFmdqrZmUaY z6Uvoc6Kmmn7zOAMxTCe9muKs14uSoHCuI4W7HRWLtLr8HydsUQoPC2r6VQ4kRr+ yY7W5sl0Jop8Vtf/6bvchQY65/xzoPX8/fJjoLee6jTeuNIPSEqd8jnC6vpyWmyh KCDkgV82BBOJ4iSYUM+OqfIOqJZoY6vuhPDK0OxTS84hpn/ACCTWEu64IyyUOJTA h9asNiBneIS/LjMfBRy+I0Yp3BYdG9hbLS35aDkSGmyNzrk98BpDWqqK/IGVABzS hO5zfhwN5JKWFNlAitwt7eay+hpF9RvbMoe+g9CfmpZSWz0qVXFHEelMq8hLhcw6 VHE8kVebAONPlD/8/bAmt8pJ/hIhs/xpFk4QRQjIzGjAuA/7L2qDxCEV12BEmCm3 mTw/VDy/5m76IIhn8DKoqG0fU/NdRKKBavr7rbHyN/gPVp1L2yJbLFXbDMF5f0KX DW0wc0IwteIbsNonaErH =C5cB -----END PGP SIGNATURE----- --Apple-Mail=_88991F9D-3093-45B7-91B1-A9B3DD5D1E9A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01205326-3312-47A1-B2B8-D8C7976F1DFD>