Kenneth Johansson wrote:
>
> "Jeff V. Merkey" wrote:
>
> > Alan,
> >
> > Were Linux to go totally modular in 2.5, development cycles will be
> > reduced by 1/2 to 1/3. This is because you could always roll back to
> > known good modules to post a release. The way you guys are going, if
> > Linux stays monolithic, your cycles will get longer and longer.
> > Modularity will allow multiple people to proceed in parallel without
> > every patch and bug going through you and Linus all the time (which
> > would mean you could enjoy more free time).
> >
>
> I don't really see what class of problems this would solve. It could be that we
> mean different things with modular. Do you mean distribute the driver source
> separately from the kernel source or do you mean going none monolitic by creating a
> stable binary interface?? I think the second one is going to be hard to get pass
> Linus and the first one is going to result in alot of drivers not uptodate with
> kernel changes.
>
Whether drivers have bugs or not should never hold up a release. The
way Linux is today, since drivers are in the main tree (true they can be
built as modules), this means Linux has to wait for every single driver
to function before a kernel can be considered stable. If MS or Novell
did their development this, W2K release cycles would be 5-6 years since
they have a huge base of drivers.
A stable binary interface. There already is one with the
register_blkdev() functions, etc. The drivers are already doing this
part, but they should not be lock step syncrhonized with the kernel.
The kernel proper could be separate. Same with the LAN and Disk
sybsystems -- they also could be instrumented as modules. A lot of this
is already there today, it's just a question of procedures and how stuff
gets managed. The driver function table has not changed for years, and
there's still the freedom to change stuff. Easy -- add a version number
to these function tables so when the kernel loads, it will know which
version table to swap in -- then you can change kernel/driver
interaction all you want and still support all the drivers.
2.4 has fewer Level I and Level II bugs at this momemtn than either W2K
or NetWare typically do when they ship. WHat's different about Linux is
that the source code is public so the whole planet knows about these
bugs. I think 2.4.0 is ready now to ship -- it's in better shape than
most commercial W2K releases are....
> The problem with a binary interface is that if it was easy to do one we did not
> need one in the first place as that would suggest that the source code interface
> also was stable.
>
> >
> > This does not solve the problem of integration testing, but eh solution
> > here is to create an integration test group whose sole charter is to
> > test modules in an integrated framework as they roll off the assembly
> > line. I am speaking from my commercial software development experienes
>
> Good luck finding anyone doing this job. It's hard to make people write
> documentation this is going to be impossible. This is a solution that works if you
> can pay people but I don't think it's going to work when volunteers is doing it.
Well. It gets done today, so who is doing this today?
>
> >
> > here. Linux is falling into the same rut NetWare did as it became
> > successful -- too much work for mere mortals without some new structures
> > put in place.
> >
> > Just a thought.
> >
>
> Yes but is anyone taking notes on what work really is taking up all the time? Is it
> really drivers that is the problem? To me it lookes more like a problem with
> deciding what really is the goal of every new version that make all sort of late
> changes creap into the kernel that increase the time to a stable version. Making
> the TODO list before instead of at the end would probably make people concentrate
> on the same thing.
Linus stated in an email a month or so back modularity was something he
really would like to see happen. Let's see just how serious he really
is when 2.5 comes down the pipe.
>
> Just another thought.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:12 EST