Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Making amd64 GENERIC a tad more "modular"



On 13.02.2011 06:24, Matt Thomas wrote:
> 
> On Feb 12, 2011, at 9:18 PM, Jean-Yves Migeon wrote:
> 
>> Hi list,
>>
>> amd64 GENERIC differs largely from i386 GENERIC by making a less
>> intensive use of of module(7) for options. In fact, most modules are
>> still compiled as "builtin" rather than being standalone kmods.
>>
>> See modstat(8) outputs for i386 and amd64, attached.
>>
>> Would the attached patch (GENERIC.diff) be acceptable?
> 
> No.
> 
> EXEC_ELF64 is the native binary format so excluding that from
> the kernel would be foolish.  I'd say EXEC_ELF32 should be present
> as well (you might be booting a 64-bit kernel on a 32-bit userland).
> 
> TMPFS needs to be there by default.

It's not really "excluded", rather provided as an external module.

Okay; should that be reflected for i386 as a consequence? Its GENERIC
does it that way:

# For GENERIC, we build the exec formats as module(7)s by default.
no options      EXEC_AOUT       # exec a.out binaries
no options      EXEC_ELF32      # exec ELF binaries
no options      EXEC_SCRIPT     # exec #! scripts
no options      COREDUMP

Note that this suggestion was not clearly approved [1].

[1] http://mail-index.netbsd.org/port-i386/2011/02/12/msg002329.html

My goal is to have i386 and amd64 installation/ramdisk/kernels as close
as possible (be cohesive between x86 architectures). So we can safely
assume that turning on/off specific options in one does not have to be
handled differently in the other, and that they behave somewhat similarly.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost


Home | Main Index | Thread Index | Old Index