applet mcelog? [was: Re: patch: unzip succeeds with CRC errors]

[Rob Landley]

On Wednesday 29 March 2006 2:57 am, Bernhard Fischer wrote:
> On Tue, Mar 28, 2006 at 04:56:04PM -0500, Rob Landley wrote:
> >On Tuesday 28 March 2006 11:28 am, Bernhard Fischer wrote:
> >> On Tue, Mar 28, 2006 at 10:24:39AM -0500, Rob Landley wrote:
> >> >On Monday 27 March 2006 1:58 pm, Paul Fox wrote:
> >> >
> >> >the user.  If that happens now, you have bad memory without ECC or the
> >> >ability to catch a machine check exception.  Has anybody actually
> >> > _seen_ this
> >>
> >> apropos... Do we want to have an mcelog applet in busybox?
> >
> >How big is it and how hardware-specific is it?
>
> The full binary (e.g. on SuSE) is:
> # size $(which mcelog)
>   text    data     bss     dec     hex filename
>   12126    1896     264   14286    37ce /usr/sbin/mcelog
>
> Which also includes dmidecode, i think.

So 14k.  On the chunky side, but not egregious.

> wrt hardware-specifics of mcelog:
> It (optionally?) uses DMI to find out stuff about the hardware (this can
> be a separate applet, dmidecode, which is handy, too).
> mcelog looks quite hardware-specific ATM, i.e. it currently supports
> p4 and k8 compatible machines.

So not relevant to ppc, mips, arm, sparc, or even most of the actual x86 chips 
used in the embedded world (via samuel and such)?

> The dmidecode applet is potentially useful on anything that has a DMI
> block, so may be useful on a wider variety of machines. I'm not sure
> which integrators/vendors on non-x86 compatible arches do support DMI
> currently. A quick grep turns up mips, ppc, didn't look closely, though.

Still, that's a plus.

Yeah, I suppose I can see it, if we can get both applets for that 14k.  Could 
I see the patch before it goes in, though?

We might want to add a hardware menu.

> >I'm a little uncomfortable with the "linux32 and linux64" applets just
> > because they're so hardware-specific, although I do see the need for
> > them.  (Speaking
>
> I don't see anything hardware-specific in linux32 and linux64.
> It just sets the personality (AFAICS exec_domain.c::__set_personality()).
>
> >of which, are those _just_ x86_64, or are they also PPC32/64 perhaps?)
>
> There is PER_LINUX and PER_LINUX32. Again, i don't see anything which is
> particularily hardware-dependant there, it's a syscall. YMMV.
>
> So, what is it that makes you uncomfortable with setarch?

I'm not uncomfortable enough to suggest it be removed or anything.  It's fine.  
There's just something unresolved about it.

Partly it's "64 bit busybox.  Is that our _job_?"  I'm still a bit surprised 
that the answer is "yes". :)

Partly I'm trying to figure out if there's an easy way to merge it with 
something else, the way fdflush and freeramdisk got merged.  Some kind of 
"make random syscall" or "make random ioctl" code that could have a clever 
invocation from applets.h.  But if there is a way, I'm not seeing it.

I brought it up in hopes I could use it to shed light on where the boundaries 
are, but apparently not.  (I dislike judgement calls where I can't point to 
_why_...)

Rob
-- 
Never bet against the cheap plastic solution.