James Bottomley <[email protected]> writes:
>
>> To some extent this also shows the mess that the x86 subarch code is
>> because it is never clear if code is implemented in a subarchitecture
>> or not.
>
> Erm, it does? How? My statement is that introducing subarch specific
> #defines into subarch independent header files is a problem (which it
> is). If you grep for subarch defines in the rest of the arch
> independent headers, I don't believe you'll find any. This would rather
> tend to show that for the last seven years, the subarch interface has
> been remarkably effective ....
They are remarkably brittle, because it is very hard to tell which code
is in a subarch and which code is not. There have been several iterations
where people have broken subarchitectures by mistake.
This whole conversation is funny in one sense because the code under
discussion won't even compile on voyager right now. Someone else
caught that and the patch that came out of that conversation was sent
to Andrew earlier today.
All I know for certain is that I have submitted patches that have
changed the entire kernel and the only thing that broke was x86
subarches because it is so non-obvious how they are different.
But I do agree the subarch header files are clean.
And no this case except for the fact no one realized that the
code doesn't even compile on voyager does not show how brittle
the x86 subarch code is. Except for the fact that it seems
obvious that kernel/smp.c is generic code that every smp subarch
would use.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
