[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: differences in busybox configurations, part1 (longish)



First I'd like to thank you for doing that but I'd also want to make
clear that we need to be conservative on udeb flavour since the
installer heavily depends on it. More bellow...

On Mon, Feb 14, 2011 at 22:06, Michael Tokarev <mjt@tls.msk.ru> wrote:
...
> Just for the record, non-static allyesconfig for i386
> produces the following:
>
>   text    data     bss     dec     hex filename
>  403449    1790    8988  414227   65213 busybox-1.17.1-9
> 1331954    2901    9180 1344035  148223 busybox-1.18.3-allyesconfig-shared
>
> I'm not sure we really need such a monster, so actual
> good question I'm still unsure about is: what's the

We surely not!

> intended usage for this tool?  The config I use here
> does not include "everything" but only the most important
> utils, especially the ones which can't be easily substituted
> with shell code fragments.

Personally I agree that all-yes is a no-go. We ought to use some
common-sense when thinking about enabling or not something.

> Most important: what's the usage for the static build?
>
> DPKG and DPKG_DEB (dpkg applet)
> Current:  deb n  static y  udeb n
> Proposed action: enable for deb, keep disabled for udeb
> Discussion: small dpkg can be useful, especially in a
> static build indeed (for repair purposes when nothing
> else can be run).  Just keeping two configs in sync
> for regular build.  For udeb it isn't needed, -- can
> be enabled but we've size constraints.  See next option.

Personally I think it shouldn't be enable in any flavour since a deb
package can be extracted with ar and tar. So easily done in case of
need.

> AR (ar applet)
> Current:  deb n  static y  udeb y
> Proposed action: drop from static and udeb
> Discussion: I'm not sure why it's used for udeb.
> May be obsolete dpkg applet.  Since .deb file is
> an ar archive, only one of these tools can be built.
> I prefer to keep dpkg since it is more debian-friendly.

deb=y

It is used on d-i since udpkg rely on it to work.

> FEATURE_NON_POSIX_CP
>  With this option, "cp file symlink" will delete symlink and
>  create a regular file. This does not conform to POSIX, but
>  prevents a symlink attack.
>  Similarly, "cp file device" will not send file's data to the device.
> Current:  deb y  static n  udeb n
> Proposed action: disable for deb.
...

Agreed.

> --- autentification, login utils ---
>
> FEATURE_SHADOWPASSWDS
> support for getspent() and friends.
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: It is quite unexpected that busybox can't
> use shadow passwords.  On the other hand, there's just
> a few applets which actually deals with passwords, and
> most of them are disabled for deb build.

I'd say to enable it on deb since it can be an important applet for
embedded people to rely on.

> ADDUSER, DELUSER, ADDGROUP, DELGROUP
> Current: deb n  static y  udeb n
> Proposed action: remove from static.
> Discussion: can be trivially done using
> some editor or "sed magic" or just 'echo'.

Agreed. At least for now it can be dropped.

> PASSWD
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: probably needs to be setuid to work well,
> but good for root-only.  Can be used from within an
> initrd to (re)set system password (alternative is
> to use editor to set it to empty string).

Fully agree.

> CHPASSWD or CRYPTPW
> (not really a difference, but suggested to be enabled
> in context of passwd utility, currently disabled)

IMO this shouldn't be enabled.

> FEATURE_PASSWD_WEAK_CHECK
> Current: deb n  static y  udeb n
> Proposed action: drop for static
> Discussion: most likely irrelevant option, since
> the checks it performs are very basic.

Agreed.

> GETTY, LOGIN, NOLOGIN, SU, SULOGIN, VLOCK
> Current:  deb n  static y  udeb n
> Proposed action: disable static
> Discussion: I'm not actually sure why all this is
> enabled for static build, it makes very little
> sense unless we really need full system in a
> single executable.

This can hurt embedded people. I am adding Hector so he can comment on it.

> INIT (init applet)
> Current: deb n  static y  udeb y
> Proposed action: enable for deb
> Discussion: small init is actually useful at times,
> I use it on our diskless workstations (which runs Debian).

Agreed.

> FEATURE_INIT_SYSLOG
> this lets init to perform syslog logging.
> Current: static n  udeb y
> Proposed action: set to n for deb after enabling
> init (by default it is enabled upstream).  RFC.

We have a busybox-syslog that depends on it, no? For udeb please let it as is.

> FEATURE_INITRD
>  Legacy support for running init under the old-style initrd. Allows
>  the name linuxrc to act as init, and it doesn't assume init is PID 1.
> Current: static y  udeb n
> Proposed action: enable for deb
> Discussion:  Is it actually needed?  The feature itself is still
> supported by current kernel, so it's probably a good idea to support
> it.  The code size is very small.

IMO it could be disabled. It is difficult to think someone is using a
such old way of booting for wheezy based systems.

> PIVOT_ROOT and FREERAMDISK
> goes together and near INITRD, since most usage is around initrd.
> Note that pivot_root is used nowadays for lxc
> Current: deb n  static y  udeb y
> Proposed action: enable for deb
> Discussion: tools for initrd (legacy but may be useful)

Agreed.

> HALT
> Current: deb n  static n  udeb y
> Proposed action: enable
> Discussion: useful system-maintenance utility

Agreed.

> --- Miscellaneous ---
>
> ACPID
> Current:  deb n  static y  udeb n
> Proposed action: disable for static
> Discussion: small acpid is sometimes useful,
> but it is mostly equivalent for a shell loop
> reading /proc/acpi/event (this interface is
> obsolete but still supported).  May be used
> for various custom buttons.  RFC.

Agreed.

> FDISK
> Current:  deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: may be not the best fdisk tool out there,
> but sometimes it's very useful in early boot to diagnose
> boot problems and the like - at least to inspect partition
> tables.

Agreed.

> HWCLOCK
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: manipulation for system time
> is useful even from initramfs

Agreed.

> MKSWAP
> Current: deb n  static y  udeb y
> Proposed action: enable for deb
> Discussion: simple utility, useful for
> rescue mode, complete implementation so
> d-i can use it too

Agreed.

> FBSET
> Current: deb n  static y  udeb n
> Proposed action: drop from static
> Discussion: legacy code, maybe still useful
> on old/embedded systems.

Agreed.

> FDFLUSH
> Current: deb n  static y  udeb n
> Proposed action: drop from static
> Discussion: legacy code, not needed most of the time,
> maybe except of some very rare embedded systems

Agreed.

> EXPAND and UNEXPAND applets.
> Current: deb n  static y  udeb n
> Proposed action: disable for static

Agreed.

> ED (ed applet)
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: probably not very useful nowadays
> directly, but can be used to implement various
> things like addgroup if needed

I think it could be dropped.

> MESG (mesg applet)
> Current: deb n  static y  udeb n
> Proposed action: disable for static
> Discussion: chmod can do this

Agreed.

> FSCK_MINIX, MKFS_MINIX
> Current: deb n  static y  udeb n
> Proposed action: disable for static
> Discussion: obsolete filesystem

Agreed.

> REV (rev utility, reverse each line)
> Current: deb y  static n  udeb n
> Proposed action: disable for deb
> Discussion: anyone use it?

Agreed.

> MAKEDEVS
> Current: deb n  static y  udeb n
> Proposed action: drop from static
> Discussion: we've mknod, and we don't
> create devices in batches nowadays since
> we've dynamic /dev.

Agreed.

> MDEV
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: very small alternative for udev,
> for all the udev haters out there.

Agreed.

> CROND, CRONTAB
> Current: deb n  static y  udeb n
> Proposed action: disable for static
> Discussion: small crond, do we need it?
> Not needed for rescue, we have real cron
> (several of them) on the system.  RFC.

Agreed.

> EJECT
> Current: deb n  static y  udeb n
> Proposed action: drop from static
> Discussion: mostly desktop-oriented command, but
> actually may be useful to eject an installation
> media.  RFC.

Agreed.

> LESS
> Current: deb n  static y  udeb n
> Proposed action: enable for deb
> Discussion: handy utility.  We've more too, but
> it can't scroll backwards.  Probably more(1) should
> go and be replaced with less, or both enabled.

Agreed.

> IFUPDOWN
> Current: deb n  static y  udeb n
> Proposed: remove from static
> Discussion: network configuration can be processed
> manually if necessary

Agreed.

> NC_SERVER, NC_EXTRA
> (netcat options)
> Current: deb n  static n  udeb y
> Proposed action: enable for deb and static
> Discussion: actually useful for rescue system

Agreed.

I am not sure it ought to be enabled on udeb. Comments?

> FEATURE_MD5_SHA1_SUM_CHECK
> Current:  deb n   static y  udeb y
> Proposed action: enable for deb and static
> Discussion: useful utility for rescue system

Agreed.

Please do not start doing those changes since this is good to have
more people commenting on those and then avoiding rework for you. I'd
say to wait few days until to really start doing this cleanup.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br


Reply to: