svn commit: r293068 - in head/etc: . mtree

[Nathan Whitehorn]

On 01/11/16 19:11, Warner Losh wrote:
>> On Jan 11, 2016, at 3:16 PM, Brooks Davis <brooks at freebsd.org> wrote:
>>
>> On Sun, Jan 03, 2016 at 06:41:33PM +0100, Dimitry Andric wrote:
>>> On 03 Jan 2016, at 05:32, Warner Losh <imp at FreeBSD.org> wrote:
>>>> Author: imp
>>>> Date: Sun Jan  3 04:32:05 2016
>>>> New Revision: 293068
>>>> URL: https://svnweb.freebsd.org/changeset/base/293068
>>>>
>>>> Log:
>>>> Add libsoft to the tree, just like lib32.
>>> Hmm, are there going to be more of these "multilib" things? :)
>> We'll want to do something about supporting hard float on MIPS.  Over
>> there it may be more of a TARGET_ARCH thing, but libsoft might be useful.
> It isn’t quite a TARGET_ARCH on mips either. I’d love to work with you
> to use this stuff  MIPS turns out to be a harder nut to crack with this stuff
> because it marks the different types of binaries differently and it looks harder
> to parse.
>
> For amv6 it is more of a transition thing, but I wanted to do it something
> approaching “correct” so that we could leverage it for MIPS.
>
>> We've also got a libcheri in CheriBSD and will eventually need to do a
>> lib64 as we explore the switch from CHERI-when-requested to
>> CHERI-by-default.
> We should definitely chat about this. There’s some easy ways to mark the CHERI
> binaries that are easier than others which would be quite helpful.
>
> So we should chat about how this would be helpful on MIPS, and not just
> CHERI-mips...
>
> Warner
>

For things that are a MACHINE_ARCH, do we want a convention of 
lib/${MACHINE_ARCH}? That seems like it would make it easily scalable 
and easier to predict than a lot of lib*. For things that aren't quite a 
MACHINE_ARCH, it's more complicated of course.
-Nathan