Re: open_transformer fork, depmod
Am 25.11.2014 18:25, schrieb Lauri Kasanen: > Hi, > > Can anyone fill me in on the reason why open_transformer always forks, > instead of straight decompressing? > > I found the original commit from 2003: > http://lists.busybox.net/pipermail/busybox-cvs/2003-November/019040.html > But it doesn't explain why the move was done. > > I ask because doing a "depmod -a" with gzipped modules results in over > 800 forks, which is surely not optimal neither from memory nor from > performance points of view. > > In the case of gzip, the uncompressed size is available, so there would > be no RAM waste in allocating the maximum specified 64mb first. For > compression formats that do not include the uncompressed size, the > fork+pipe approach does save RAM, but for gzip it seems to be needless > overhead. > > - Lauri > hi Lauri, so far i understand is the code idea to pipe the daten before doing the work, fine for tar (like: gzcat file | tar -xzf-) i guess that was done to avoid creating an gunzip function call. In the moddep case this will result in calling the gzcat everytime a compressed module is found. Maybe you can make a special function that extracts only the required information and the drops the rest. re, wh ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] udhcpd: discard saved leases if conflicting with static_lease config
On Wed, Nov 5, 2014 at 9:33 PM, Michael McTernan
wrote:
> Hi All,
>
> There's a FIXME in udhcpd which describes a small corner case when saved
> leases are read and honoured even if the IP or MAC of that lease overlaps a
> static_lease from the config file. I found that because of this, after
> updating config and restarting udhcpd, a client which already had a lease can
> continue to renew that lease instead of either getting the IP specified in a
> new 'static_lease' config item, or being nak'd and assigned a new free IP.
>
> Following is a small patch which removes the FIXME and adds a check to
> discard saved lease records if they would conflict with a static_lease from
> the config file.
>
> In my configuration, this added 48 bytes to the stripped executable. I
> tested it by defining a /24 subnet and adding static_lease records for all
> but 1 on the available IP addresses, and then moving that 1 available IP
> around while reconnecting a single client. After the patch, verbose logging
> and Wireshark show NAK and then offering of the single free address, with the
> client having it's IP updated each time ipconfig /renew is issued.
>
> Please consider for inclusion to busybox.
>
> + // Check if there is a different static lease for
> this IP or MAC
> + slnip =
> get_static_nip_by_mac(server_config.static_leases, lease.lease_mac);
> + if ((slnip != 0 && slnip != lease.lease_nip)
> +|| (slnip == 0 &&
> is_nip_reserved(server_config.static_leases, lease.lease_nip)))
> + continue;
> +
I'm going with a somewhat different version:
+ /* Check if there is a different static lease
for this IP or MAC */
+ static_nip =
get_static_nip_by_mac(server_config.static_leases, lease.lease_mac);
+ if (static_nip) {
+ /* NB: we do not add lease even if
static_nip == lease.lease_nip.
+*/
+ continue;
+ }
+ if
(is_nip_reserved(server_config.static_leases, lease.lease_nip))
+ continue;
Thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
open_transformer fork, depmod
Hi, Can anyone fill me in on the reason why open_transformer always forks, instead of straight decompressing? I found the original commit from 2003: http://lists.busybox.net/pipermail/busybox-cvs/2003-November/019040.html But it doesn't explain why the move was done. I ask because doing a "depmod -a" with gzipped modules results in over 800 forks, which is surely not optimal neither from memory nor from performance points of view. In the case of gzip, the uncompressed size is available, so there would be no RAM waste in allocating the maximum specified 64mb first. For compression formats that do not include the uncompressed size, the fork+pipe approach does save RAM, but for gzip it seems to be needless overhead. - Lauri -- http://www.fastmail.com - Send your email first class ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
