[oe] [oe-commits] org.oe.dev PDA-like machines with card slots: Enable "vfat" feature.

[pHilipp Zabel]

On Dec 18, 2007 4:05 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello pHilipp,
>
> Tuesday, December 18, 2007, 4:38:45 PM, you wrote:
>
> > On Dec 18, 2007 12:35 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> >> Hello pHilipp,
> >>
> >> Tuesday, December 18, 2007, 12:17:27 PM, you wrote:
> >>
> >> > On Dec 18, 2007 3:47 AM, pfalcon commit
> >> > <openembedded-commits at lists.openembedded.org> wrote:
> >> >> PDA-like machines with card slots: Enable "vfat" feature.
> >> >> * FAT-formatted cards are commodity, it's expectable them to be supported OOB.
> >>
> >> > A machine feature "vfat" sounds strange. I think machine features
> >> > should be about the hardware capabilities.
> >>
> >>   Yep, with this common sense in mind I quickly replied to Rod that
> >> introducing it wouldn't help with "bloating" issue. Well, it instead
> >> COMBINED feature.
>
> > Combined or not, I think vfat has no place in the machine features list.
> > The same goes for ext2 IMHO, and having hdparm in task-base-ext2 is even worse.
> > Shouldn't there be a MACHINE_FEATURE hdd or ide/ata/pata/sata/scsi instead?
> > The problem is that there is no easy way to ask for "X in
> > MACHINE_FEATURE and Y in DISTRO_FEATURE". COMBINED_FEATURES obviously
> > only supports "X in both".
>
>   LOL. I did say I don't want to open up this Pandora box now ;-).

I agree that this is not something for the RC phase.
I'm just voicing my concern, seeing stuff creeping into the
MACHINE_FEATURE list that I believe doesn't belong there.

> I'll leave this for you and Rod, he for example thinks that task-base
> is in perfect shape ;-).

Unnecessary.

> > So now that we have the easy method implemented, let's strive for a correct one.
> > I'd say vfat as other file systems should be a distro-only feature,
> > cardslot (or "removablestorage") a machine-only one:
>
> > "vfat" in DISTRO_FEATURES and "cardslot" in MACHINE_FEATURES --> task-base-vfat
> > "ext2" in DISTRO_FEATURES and ("cardslot" in MACHINE_FEATURES or "hdd"
> > in MACHINE_FEATURES) --> task-base-ext2 (without the hdparm
> > dependency)
> > "hdd" in MACHINE_FEATURES --> hdparm
> > etc.
>
>   Yeah! And we should add Prolog interpreter to do those inferences!
> No, Prolog sucks, let's add Lisp. Let's do some AI in OE!

Yay hyperbole. Have a look at the __anonymous function in task-base.bb
and tell me again that there is no use for boolean logic here :)

>   Seriously, why don't we leave that for some new year and clean up
> real dirtiness now and polish frontyard instead?

It is not my intention to stop anyone from polishing!

>   And if you ask for discussion, then I hope idea behind the irony
> above is clear: all that would add entities without real necessity and
> our ability to handle them. What was the aim of task-base
> introduction? To build images both full-featured and efficient in
> terms size. Does this work? Yes, and as pointed out by Koen, we actually
> should start to look for bigger inefficiencies as the image content
> list is already not too bad.

My concern is not about image size, but about watering down the
meaning of those variables.
Already now fic-gta01.conf adds the vfat and ext2 kernel modules to
MACHINE_EXTRA_RRECOMMENDS
manually, maybe because it doesn't need hdparm. And I bet there is
more duplication like that.

cheers
Philipp