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