Re: [Xenomai-core] Porting xeno-{info|load|test} to a busybox system

[Philippe Gerum <rpm@xenomai.org>]

Jim Cromie wrote:
> Philippe Gerum wrote:
> 
>> Jan Kiszka wrote:
>>
>>> Jim Cromie wrote:
>>>
>>>> Niklaus Giger wrote:
>>>>
>>>>> Am Freitag, 26. Mai 2006 15:52 schrieb Jan Kiszka:
>>>>>
>>>>>
>>>>>> Niklaus Giger wrote:    ...
>>>>>> If anybody has a working target with a Xenomai + BusyBox 
>>>>>> combination and
>>>>>> would be willing to test drive my changes, I would appreciate a 
>>>>>> feedback
>>>>>> enormously.
>>>>>>  
>>>>
>>>>
>>>> I hope this isnt waiting on my 'approval'.
>>>> I think its a great idea, and has been on my (way too stagnant) list 
>>>> for
>>>> a while.
>>>> Your work has at least urged me to install busybox on my xeno-box. ;-)
>>>>
>>>> My only concern is whether we've sufficiently distinguished the issues:
>>>>
>>>> 1 - ash vs bash
>>>>
>>>> Its not entirely clear to me which flavors of sh busybox has:
>>>>    ash / dash / not-bash
>>>> I gather u worked with ash, and it seems most valuable sh features
>>>> work there just fine ( shell-functions, even 'job-control' of a 
>>>> fashion)
>>>>
>>>> 2 - busybox 'executables' only
>>>>
>>>> I coded in a lot of 'full linux' gimme's, like zgrep, script, etc.
>>>> Niklaus has repaired many of these.  I think a more thorough cleanup is
>>>> possible,
>>>> esp if things like 'script' are jettisoned for a simpler 
>>>> shell-functions
>>>> or helper scripts.
>>>> This all implies a re-write, which is on my list...
>>>> (esp the job-control testing and repair)
>>>
>>>
>>>
>>> Just stumbled over this again while cleaning up my mailbox. What's the
>>> status? Waiting for improvements, or waiting for /someone/ to type svn
>>> ci (and improve the topics above later)?
>>>
>>
>> It's queued for now, waiting for a combined ack to merge the current 
>> patch from JimC and Niklaus.
>>
> 
> AFAIC, Niklaus is in the lead atm.
> Im trying to get some GPIO stuff ready for -mm.
> ( I'll post separately on this ..)
> 
> I ran his changes once, I dont even remember what it did.
> (which suggests that it didnt explode ;-)
> IMO, take it when Niklaus says its ready.
> I have some local changes here, but Ill work them into shape after
> Niks changes go in (maybe much later :-(
> 
> We should probly confer on the longer-term issues too.
> 
> - a rational option-pass-thru, or a means to avoid doing so.
> if we assume OPTS_${TOOLNAME} exists, we could
> grab it out of env, and pass it into the benchmark prog.
> - would require no prog mods, but gives us complete control
> - would play nicer than assuming -T <secs> has meaning for all progs.
> 
> 

Would this fit with an automated test 'bot? Niklaus?

-- 

Philippe.