tech-toolchain archive

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

Re: config(5) break down



On Thu, Mar 25, 2010 at 03:44:10AM +0000, David Holland wrote:
> On Fri, Mar 19, 2010 at 02:49:37PM +0000, Andrew Doran wrote:
>  > > I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
>  > > are never, ever downloaded any more.
>  > 
>  > Right, and these dead ports must be euthanized.  The mountain of
>  > unused device drivers and core kernel code is a signficant hinderance to
>  > people working in the kernel. 
> 
> Speaking from the point of view of repeatedly touching every namei
> call anywhere in the kernel... I'd have to disagree. Sure, it'd go
> faster if there weren't a pile of legacy binary compat implementations
> or if we removed all the mostly-unused fses, but if I wanted a toy
> kernel I already have a pile of those in the office. Most of the
> issues that the "dead" ports or fses trigger are real design or
> structural problems that would be only masked, not resolved, by
> removing that code. Supporting all the random bells and whistles that
> e.g. compat_svr4 wants from namei is part of doing it correctly, and
> having the correct infrastructure in place that can support these
> things is important because the need/desire/demand will come along
> again; it always does. For example, the $ORIGIN thing in ld.elf_so is
> actually the same as one of the annoying cases in (IIRC) compat_svr4...
> 
> I know we don't exactly see eye to eye on these issues but perhaps we
> can reach some kind of middle ground?

That's a nice story.

I'm speaking of low level kernel code and driver drivers, areas that to 
date you have had relatively little involvement in.  I will however
consider discussing the points you raise if/when I launch a jihad against
emulations and file system code.



Home | Main Index | Thread Index | Old Index