fdrv appears in DISTRO_SPECS but is not loaded

[peabee]

fdrv is listed in DISTRO_SPECS along with adrv and ydrv but....

adrv and ydrv are loaded automatically
fdrv isn't

They should behave in the same manner?

Puppy default filenames...

Note, the 'SFS' files below are what the 'init' script in initrd.gz searches for,

for the partition, path and actual files loaded, see PUPSFS and ZDRV in /etc/rc.d/PUPSTATE

DISTRO_PUPPYSFS='puppy_LxPupSc_16.05.3.sfs'
DISTRO_ZDRVSFS='zdrv_LxPupSc_16.05.3.sfs'
DISTRO_FDRVSFS='fdrv_LxPupSc_16.05.3.sfs'
DISTRO_ADRVSFS='adrv_LxPupSc_16.05.3.sfs'
DISTRO_YDRVSFS='ydrv_LxPupSc_16.05.3.sfs'
DISTRO_PUPPYDATE='May 2016'

[01micko]

It's a kernel line option. See init

[peabee]

Why is it treated differently??

BTW - interest comes from @gyro's new up to date firmware .sfs

On 29/05/16 11:50, Mick Amadio wrote:

It's a kernel line option. See init
https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/woof-code/huge_extras/init

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#785 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFpv0TICa37jhaDsFnATecaOI2anX6jPks5qGW93gaJpZM4IpQpO.

[peabee]

I would like to ship firmware as an fdrv in the iso (in a similar way that I'm shipping the browser as an adrv) but this would only work if fdrv was treated similarly to adrv and ydrv and loaded automatically with no need to specify kernel line options.....

People could then swap to different firmware - e.g. gyro's new .sfs's - easily by just replacing the fdrv....

The fdrv mechanism would also mean the huge_kernel zdrv would not need to be amended post kernel-kit build to add in firmware.

Thanks
peebee

[wdlkmpx]

Makes sense.. if fdrv is there, then just load it. If it's not, then don't. Looking at the code this looks like something easy to do.

I just committed some changes by gyro
2d1f773

Maybe he himself can do what you want... but I wonder what the team has to say about it. Any opinions?

[01micko]

The reason for fdrv is basically outlined in #558

The building of the fdrv is automated in kernel-kit. Firmware that doesn't include a corresponding module is discarded. It is certainly possible to build a kernel from kernel-kit enabling all the latest firmware for each module produced; well that's the theory and it is all built into the kernel_modules sfs and no fdrv is produced.

[wdlkmpx]

I used the kernel-kit, i don't recall clearly even when i did a lot of edits, that modded and unfinished version is posted in the forum.

That kernel_modules.sfs is in fact the zdrv isn't it?

[gyrog]

I agree with peabee's idea that the presence of an fdrv should be enough of a trigger for it to be loaded.
Since the fdrv covers the zdrv, the iso could be shipped with a "common" fdrv, removing all firmware from zdrv.
Or the iso could be shipped with the "common" firmware in the zdrv.
If a user has firmware problems, an "extra" or "all" fdrv is downloaded either fixing or eliminating any firmware issue.

[01micko]

Ok, if we go that way then fdrv should be the standard. IE; no firmware in the kernel_sfs (zdrv). That makes them interchangeable. I think @gyrog has argued for this previously.

BUT.. @mrfricks is in the middle of xenialpup dev and less disruption the better for now.

I am open to a new branch being created to merge into testing at a date in the not too distant future.

[gyrog]

When the new branch is created, if you comment here, I can generate a pull request to remove the $EXTRAFW conditionals.
I have a couple of "tidy" commits to do anyway:

1. Move the fdrv load code to follow the zdrv load code.
2. Remove references to tmpfs mount points that are no longer used.

@01micko,
If no new branch is created, could you please post here to let me know when you consider it safe for me to generate a pull-request against "testing".

[01micko]

This can probably be closed as it should be addressed by #789

I'll leave it to the OP.