Re: what is the whole purpose of kernel-image-di?
Ben Collins wrote:
> 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 :)
kernel-image-di is using for 2.4.0, will build for 2.4.1 once source
for that enters the debian archive. See its build dependancies; the
build dependancies will ensure it is autobuilt with the right kernel.
> > 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.
The reason to use modules is mainly one of space on the boot media. If
that is not a concern on sparc they could be built in.
> 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?
No, I'm really expecting porters to jump in now and help us. We have a
very small group working on this.
> 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.
As far as I can see, they have been. After all we didn't wander off and
use the busymox insmod, iirc the issues with parted have been brought up
before, and now I know about nano (which exists as a udeb just because
its mtaintainer wanted to do it iirc; we haven't really talked about
editors yet).
I encourage you and anyone else to read this list and keep us in line if
we begin to wander off into i386 la-la land. I also encorage people
involved in other architectures to begin participating in the creation
of debian-installer *now* so they can have a hand in making it work well
on those platforms.
--
see shy jo
Reply to: