deorbiting /usr/lib/libstand.a, moving to sysboot

[Warner Losh]

> On Oct 9, 2017, at 5:19 PM, John Baldwin <jhb at FreeBSD.org> wrote:
> 
> On Monday, October 09, 2017 10:21:53 AM Warner Losh wrote:
>> On Mon, Oct 9, 2017 at 10:15 AM, Ian Lepore <ian at freebsd.org> wrote:
>> 
>>> On Mon, 2017-10-09 at 10:09 -0600, Warner Losh wrote:
>>>> On Mon, Oct 9, 2017 at 10:04 AM, Ian Lepore <ian at freebsd.org> wrote:
>>>> 
>>>>> 
>>>>> On Mon, 2017-10-09 at 17:57 +0200, Dimitry Andric wrote:
>>>>>> 
>>>>>> On 9 Oct 2017, at 07:45, Warner Losh <imp at bsdimp.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I'd like to deorbit /usr/lib/stand.a and /usr/include/stand.h.
>>> These
>>>>> are
>>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> 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?
>>>>>> 
>>>>>> -Dimitry
>>>>>> 
>>>>> 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.)
>>>>> 
>>>> They can email me and I'll help them convert over... :)
>>>> 
>>>> Warner
>>> 
>>> 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?
>>> 
>> 
>> The proposal is to take it 100% internal and officially not support its use
>> outside the loader.
>> 
>> 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.
> 
> 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’s not been true for a long time….

libstand32 pulls from lib/libstand, or did until recently.
userboot/libstand likewise.

sys/boot needs both to build. It’s historically been under sys since around V32 if my sleuthing is right, though there’s 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’ve hopelessly mixed up the clean separation of low-level ‘boot1’ 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’t packages together for size reasons). Not sure that it’s worth sorting that last stuff out at this late date though…

That’s a long way of saying “I’d support moving it to src/$(result-of-bikeshed sys/boot)” but that’s not what I’m doing today.

Warner

P.S. Since there was no pushback, and evidence of a ton of pent up demand, I’ve gone ahead and pulled the trigger on the move.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20171009/e45354b1/attachment.sig>