Re: Proposed changes to installer for armhf
On Thu, 2014-04-24 at 13:58 -0400, Martin Michlmayr wrote:
> * Ian Campbell <ian.campbell@citrix.com> [2014-04-19 19:50]:
I must have used the wrong email account earlier, switching to my home
address here...
> > I'm a bit worried that this might imply a greater level of support for
> > any board with a DTB than we actually offer. Not really sure how to deal
> > with that, probably more of a docs issue than anything.
>
> I have two concerns:
>
> 1) Like you, I'm not sure whether making all DTBs available is a good
> idea when we don't support all devices. How about only copying the
> DTBs for devices that we know are supported by d-i and Debian?
How do we know/define which ones we Support though? It seem pretty
fungible to me (AFAICT it is based on drive by itch scratching as much
as long term commitment).
People seem to run Debian on all sorts of things which we don't
"Support", and in the world of single image multiplatform kernels I
don't think that such a bad thing compared to the old days which would
have involved separate kernels etc (even if support was somewhat simpler
to define under those circumstances).
I guess I dunno, I'm uneasy but I think erring on the side of not
putting barriers (like hiding the dtbs away in a .deb) feels more right
to me.
> 2) I wonder whether providing the kernel as a stand-alone file and the
> DTBs as separate files is enough, i.e. can we assume that people are
> capable of catting both files together? Maybe it's better to provide
> kernel images with embedded DTB for the devices we support.
For much of the modern stuff you don't need to cat things together any
more, the bootloader supports FDT.
Anyway, someone who can't manage to run cat seems unlikely to make much
progress for other reasons. Or at least they are going to have to be
following some pretty specific instructions, and adding a cat invocation
into that doesn't seem like such a stretch then.
> Actually, maybe combining the two would be a solution: offering all
> DTBs are stand-alone files, and for the devices that are known to be
> supported also offer a kernel+DTB file that's easy to download (since
> it's a single file).
Appending the DTB is actively wrong for many platforms though, so it
doesn't help all that much, since you'd still need to have separate DTBs
for those.
[...]
> Another advantage I see with this approach is that if some board
> support wants to add a preseed file to set specific values, it would
> need a subdirectory anyway; so maybe going with one generic
> kernel/ramdisk and then one with each supported device is a good
> approach.
IMHO it would be better to have the installer DTRT on those boards than
to proliferate the number of images just in order to preseed something
for a given board. DI can always probe /proc/device-tree/model, or even
pick a default preseed based on it.
IOW I think we should aim for the minimal number of images we can,
adding new ones for different broad functionalit9ies (netboot,
netconsole, netboot-gtk etc) rather than different platforms.
> Maybe this is not needed but at least I thought I'd express my
> thoughts.
Thanks! It was useful.
Ian.
Reply to: