[PATCH] hdparm utilizes shared memory for no good reason ?

[Paul Fox]

rob wrote:
 > On Tuesday 16 May 2006 5:08 pm, Paul Fox wrote:
 > >
 > > if the options are left in, and the results are arguably suspect, then
 > > the tool should print a big fat warning that it's not the same as
 > > the "real" hdparm.
 > 
 > Calm down.  

:-)

...
 > Also, there is no "real" hdparm.  That's totally the wrong
 > _conceptual_ approach.  If the busybox version can't do the
 > job then we don't have the tool, but if there's just an
 > implementation that you can't even DERIVE a spec from then I'd
 > argue nobody has any business using the tool at all.

i'm not quite sure what you're getting at.  the "real" hdparm is
the one that's being emulated by the busybox applet.  if all we
wanted was a disk option manipulator, we wouldn't need to use the
hdparm name, could probably drop a bunch of options (and
therefore get under the 32 option limit that's caused such
panic), and could do the timings however we wanted.  but if
you're going to call it hdparm, it should probably be relatively
true to what hdparm does.  or, like iwconfig, or iptables, or any
of a number of other rather large specific-purpose tools, we
could leave hdparm out of busybox, and no one would be much the
worse for it -- they'd just use the "mainstream" implementation
instead.

(mainly, i guess i'm both bugged and amused by the incongruity of
trying to minimize the number of Kbytes consumed by a program
whose sole purpose is to manage storage device that don't come in
sizes less than a gigabyte anymore.)

paul
=---------------------
 paul fox, pgf at brightstareng.com