Lets start here
OpenWrt does not currently run on devices which have 2MB or less of
flash memory. This limitation will probably not be worked around since
those devices are most of the time micro-routers, or Wireless Access
Points, which are not the main OpenWrt target.
This reads to me only as not primary target. Not as in "we do not
support that". It simply states what was the case at the time of
writing. Also my understanding of the community project openwrt is not
to exlude anybody or some purpose. See the list of growing platforms for
example. It is like a living organism. If there is a need or somebody
willing it is done. If there is nobody by now, maybe somebody comes
around later.
What makes openwrt so unique is the vast amount of possibility. There is
a small set of readymade images. But if you want to buildroot yourself
the tiniest embedded Linux you need, well it is possible.
Device Dependent is for things like block-* that depend on having
'external' (non-boot rootfs) devices , or on certain wifi devices (like
Device dependent says nothing specific. Even worse, it sounds like
something that should change according to the chosen device profile. How
about "additional/external storage support"? This way the user would
know what to expect in the category.
the toggle you mentioned before). It's more general than
hotplug-scripts because it includes things other than just hotplug
scripts.
Do you have more packages you want to put in there? Maybe we can come up
with a less generic name.
I think I'll wait to you've digested the correction on what's essential
and what's not and the total size of the hotplug code. I also would
And again .. it sums up. Having said sad I am glad to hear that the
block mount scripts are not that tightly integrated in the boot process
as I expected. Hence I gladly add it to the optional package list, see
below.
like you to really think about the issue of badgering the user because
they didn't fill a dependency (that is have scripts that are trying to
execute functions but can't because the programs to do it aren't there).
You got me wrong. Read on.
I think it's fundamentally flawed. Warning the user if they've
configured things badly is different than failing to fill a dependency
automatically when the promised functionality depends it.
Dependencies reflect absolute requirements. Fs utility packages do not
require the fsck.sh scripts. E.g. e2fsck works perfectly alone. The same
with usb storage. This works if the new scripts are installed or not.
The script merely offer a sophisticated way to deal with it.
What we have here is a dynamic dependency
e.g. blkid. Buildroot does not know if the user is going to configure
the use of uuid or label mounts. Therefore it is a dependency that
starts when the user configures the system after flashing. Hence there
must be a way to tell him/her what is going on.
Same for fs tools. Only because basic addstorage support is installed,
this doesn't mean that the user is going to use an fsck.* app. This is
decided later, if he decides to uci config a file check. In that lies
the real quest.
Easy solution is error log output. Better is putting comments where the
fsck'ing is configured. Perfect would be a tool that helps to configure
and checks for pitfalls. I actually opt for Easy+Better.
Circumvent dynamic dependencies is only possible by splitting the
promised functionality out of the big package to the effect that the
small package wouldn't run if the dependency is missing. This is extra
difficult here because of the multiple choice of filesystems. And there
might be more in the future.
The reason I divided the packages the way I did is so the the scripts
weren't installed unless package that provided the capability to provide
the function was present. e.g. btrfs fsck script only included when
btrfs-progs is.
Cleanly these fsck scripts should be packaged each as a package that
depends on the appropriate fs tool and the basic blockmount. But this is
more hassle than it's worth and therefore putting into their respective
fs tools package serves the purpose fine.
Initially the core of the block-mount was to be included in base-files
(which is what what you're talking about switching to again, but I might
This was because I was under the impression they weren't optional.
as well have left things the way I had them if we're going to to do
that, because there is 5-8k of scripts that are hotplug only, and that's
it), and the other script functions were to be added along with the
package that provided the program need to use it. You didn't like that
because it was too big.
Moreover I oppose to the idea to waste space on code that the user does
not/ can not use.
The thing unless you subdivide to fairly small chunk you can't have a
proper matching of scripts to available functionality.
Agreed see "Circumvent dynamic dependencies..." above.
I am personally
opposed to installed the scripts willy-nilly and spamming the syslog
with error messages if the dependencies aren't met. I think that is bad
design. It's much better to include the script only if it won't cause
the user to get error messages.
True, but not always reasonable and possible. For example when the
dependency like swapon can be delivered by several packages. Or the
parts are that small that cluttering them over several packages is
opposed to because they should for maintenance stay in on package
(another option for the fsck.plugins). Or what about users that activate
the fs kernel modules for ext2, xfs and ext3. You cannot conclude that
they are gonna need the respective fs tools for these. Possible, but not
conclusive.
> Now if the user uses a config file with unsupported functions that's a
different story...that's a configuration error.
It is similar to say .. try to configure the firewall but you miss a
iptables plugin. Dynamic dependency. To solve it you have to install
whatever functionality is missing. The only other way is putting
everything in, even if the user only needs a fraction. But this is
unfortunately no way to go on embedded devices. From usability
perspective this could be ideal with proper interface design (if the
user is not confused by the magnitude of choices).
me neither ;) .. but seriously. Circular dependencies only mean that
somebody did not look deep enough into setting them properly.
Not true, with the limited dependency language we have.
Show me an example that is not solvable.
1) Package C should be installed if both package A and be are B are
installed (because of user expectations; A implies that it will use the
functionality of B, if present, but that requires C)
2) Package C depends on A and B
Dependencies are no questions of should. And also not of user
expectations. Unfortunately. No dependency system can solve that. At
maximum the system can suggest, but eventually users have to decide and
user interfaces have to hint if something goes wrong. The machine is
only as capable as the person using it.
In my understanding I distinguish between basefile-block-(mount,fsck(
and the hotplugd-block-(automount,fsck). The basefile functionality is
there anyway, the hotplugd is optional. Actually users do not need
There's no point to that. Hotplug only code accounts for<9k of
scripts, total. In that case we should just got with my previous patch
and forget about the separate packages.
well it is space ;)
ok, to summarize.
My major concern is to have valuable space wasted for users without even
the possibility to add additional block devices. Therefore my suggestion
for now is a packaging like that.
menuconfig->Base system
-> extended additional storage support* (ucified fstab support, fsck)
-> hotplugd-block-automount (enables automount feature, autoselects *)
-> hotplugd-block-fsck (enables fsck on hotplug, autoselects *)
This keeps mini routers clean, but can be added to sophisticated
devices. Or it is selected by default but can be removed for minimal builds.
.. how 'bout that :) kind regards ede
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
