On 07/13/2011 03:13 PM, Laurent Bercot wrote:
Specialized filesystems such as jffs2 or yaffs2 still can, however.
Good point, but a lot of, for example closed, embedded/mobile devices
require a lot of hacking around to get something custom (like a
different fs) running.
Why shouldn't it be? Either you want to reduce the number of writes
to the filesystem, or you don't. Delayed writing, which is configured
at the filesystem layer, accomplishes this for every application without
the need for patching. Applications can always fsync() when they need
synchronous writes.
True, but generally those writes from other applications are going to
happen anyway. E.g. if I save a file in application X, it will need to
be written out, and be written out completely. For BusyBox's history,
this isn't the case. I don't see why a file has to be written out after
each appended line here. Vi doesn't write out a file after each new line
either, does it?
Of course, you could argue why BusyBox' history _should_ be written out
after each command, but that's why the introduced buffer is behind a
CONFIG_* option; you don't have to use it.
Patching an application to suit your specific needs is cleaner than
writing two lines of script to achieve the same purpose ??
I've posted this patch to this mailing list because I thought it might
be of use to more people. Think about Maemo/Android users for example.
This isn't about specific needs.
I fully understand that patching a single application to solve a more
global problem isn't ideal either. However, as I said in a previous
email, this is justified (in my opinion) because BusyBox is a 'more
heavy offender', writing out a file after each and every command. Of
course, this is relative and depends on how you use your device, but
even then BusyBox could be a little bit more sensible about writing out
its history file. For example, several other popular shells keep the
shell history in memory during a shell session too.
--Dennis
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
