Re: what is the whole purpose of kernel-image-di?
On Tue, Feb 06, 2001 at 09:09:28PM -0800, Joey Hess wrote:
> b. Send me an appropriate kernel config and related information, and build
> kernel-image-di once I integrate it.
Well sparc needs three kernels. sun4cdm, sun4dm-pci and sun4u. I can get
you configs, but the problem being that I have no idea what kernel
source you are building. I would hope that you plan to integrate to
2.4.x sooner or later, but how will you notify ports of this new change?
No one asked about such configs yet. I guess what I am saying is that it
would be nice if you could communicate this outside of the debian-boot
list (say to the nice debian-ports@l.d.o alias I have made :)
> c. Some things such as network card involve hardware autodetection. We have
> concentrated on i386 since it has the most variety (and crap) hardware.
> udebs are generally available which let the user specify it manually
> instead of using hardware autodetection. Other than those and some minor
> crossovers, other architectures are on their own, and someone will have to
> work on it.
Well sparc is quite simple in this regard. We have the special ability
to just build all the standard NIC drivers right into the main image.
The only modules I can think of needing are for the gigabit, but I
imagine those are not needed for the installer, since nearly every sparc
has one of the standard cards built-in.
> d. The build/ directory is what builds actual bootable media. That code is
> currently flagged:
> # Create a bootable floppy image. i386 specific. FIXME
> Obviously that will need to be fixed, on a case-by-case basis. I personally
> flag anything I do that is i386-specific as such, although I haven't
> had to do that much so far.
>
> But we're really all too busy writing this thing to have ready-made checklists
> yet. I'm scrambling to keep the existing design documentation current.
That's fine, but is it even a concern to have such a checklist, or is me
bringing it up the first of it's discussion? Are you expecting porters
to do all the work trying to figure out what they need to do once the
installer is nearly complete?
> > Note, every arch is different, which was the main reason for so much
> > speciality and hacking in the boot-floppies. It's held together by
> > ducktape and string. Have the issues involved in the boot-floppies
> > struggle with multi-platform support been brought into consideration of
> > the debinst design?
>
> You're not going to magically get a new installer for your architecture
> dropped in your lap, it will take work. Anyone is free to jump in and make
> support for another architecture happen *now*, while we are still in the
> middle of writing the thing. Or you can wait and complain after the fact
> about us not anticipating the needs of every architecture. Up to you.
I'm not asking for a free-installer. What I'm asking for is
concentration on porting specifics. Not all porters can keep up with the
entire installer code base, and simply want to know "what do I have to
do to get support for my arch in the installer?". If I have to go
through the whole source tree searching for "i386.*FIXME", it's going to
be slow and tedious. I'm not expecting anyone to do the work for me, but
as the developers of the software, I would hope that keeping known
concerns about porting in the focus of the project would be a main
concern.
Obviously if I jump up and say "well arch foo needs 10 special udeb's,
why don't you have them!", well piss on me. But if I turn around and see
that there is no way for me to even have subarch (sun4cdm, sun4u)
support, then piss on debinst. One issue that comes to mind was the past
discussion about using the module utilities from busybox, which would
have totally killed some ports (sun4u being one of them). Things like
that need the concern of more than just one or two archs. The other is
the nano editor, which has asm for i386 only (or maybe some other archs,
but surely not sparc). This means we don't get the space savings that
i386 does (it has to link to libc).
Other choices may include things like parted, which doesn't support all
archs, but I hear it is a likely candidate for a partion program. Yet
more things to shutdown certain ports from using the standard install.
Of course it isn't a reason not to use it, just that concerns need to be
raised.
Please don't think I am complainging about what work I will have to do,
or that you guys aren't doing enough, I'm just concerned about a lot of
work being done without enough consideration for the effects on other
ports.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: