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

[Rob Landley]

On Wednesday 17 May 2006 4:44 pm, Paul Fox wrote:
>  > 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.

We provide a set of functionality.  We don't "emulate" anything.

We provide an app that does X.  If there's a spec, we try to implement it.  If 
there are user expectations, we try to meet at least the obvious ones.

> 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.

Sounds like a good approach to me.

> but if you're going to call it hdparm, it should probably be relatively
> true to what hdparm does.

Show me the spec for hdparm.

> 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.

We can do it smaller.  We have the technology.

> (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.)

Why can't you hdparm's speed test against a USB flash key?

Rob
-- 
Never bet against the cheap plastic solution.