This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86 maintainers


Certainly all flavors of x86 should be handled together.

In recent times, the x86 code has been maintained by drepper and schwab,
with hjl et al doing the pure-compute optimized assembly code (string and
math) though with active review.

I'm not entirely convinced that x86 should be treated like the other
machines.  For one thing, it's the one machine (x86_64 anyway) that
basically everybody uses.  So perhaps it is sufficiently covered by
collective action as with the main generic body of the code.  

In another vein, x86 is clearly the most important machine (affects the
most users, by 1000:1 or something).  So it merits greater scrutiny than
the average machine.  It's probably appropriate that x86-specific changes
always get some amount of collective thought, as opposed to the less
important machines where a single arch maintainer committing what he thinks
is right without discussion is more often fine.

It's also usually the model for other arch maintainers.  Hence, many
x86-specific changes merit special review with an eye toward both
exemplifying the best practices for any port, and being as clear as
possible in comments, style, etc. when other arch maintainers or future
porters read the source as a model for what to do.  That is, the x86 code
should not only do things the best ways it can, but also make very clear
when it's doing things a certain way because of quirks of the x86
architecture or ABI, or arcane historical compatibility issues other
machines won't have.

So while it's clearly worthwhile to identify the canonical x86 experts who
know the machine details the best, I am not sanguine with it getting the
same "arch maintainer commits at will" treatment as other machines.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]