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