Hi All,
My company is porting uClinux to our processor architecture that is used
in several routers and some digital picture frames on the market. We
started with the 20080808 distribution (2.6.25-uc0 kernel) and have a
kernel up and are adding drivers and user mode code currently.
Our architectu
Hi Rainer,
Rainer Keller wrote:
My company is porting uClinux to our processor architecture that is used
in several routers and some digital picture frames on the market. We
started with the 20080808 distribution (2.6.25-uc0 kernel) and have a
kernel up and are adding drivers and user mode code
I can clarify one thing - the code on Source Forge is identical to what is
on uclinux.org.It is preferred that downloads be done from Source Forge, as
it's sole purpose is to unload uclinux.org.
If any issues are found with the Source Forge files, please post here, as I
monitor this list and will
No, not exactly either. Almost all of the current code in the kernel
for non-mmu is conditional on CONFIG_MMU.
With user space stuff I always found the "EMDED" define which often is
used to do a fork() vs. vfork() selection.
(Which IMHO in many cases seems silly, as AFAIK, you can happily use
My company is porting uClinux to our processor architecture that is used
in several routers and some digital picture frames on the market.
Is it a secret which arch you are talking about ?
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
Hi Michael,
Michael Schnell wrote:
No, not exactly either. Almost all of the current code in the kernel
for non-mmu is conditional on CONFIG_MMU.
With user space stuff I always found the "EMDED" define which often is
used to do a fork() vs. vfork() selection.
That was certainly the case many
Jivin Michael Schnell lays it down ...
>
> >No, not exactly either. Almost all of the current code in the kernel
> >for non-mmu is conditional on CONFIG_MMU.
> With user space stuff I always found the "EMDED" define which often is
> used to do a fork() vs. vfork() selection.
>
> (Which IMHO in
(Which IMHO in many cases seems silly, as AFAIK, you can happily use
vfork() if there is
an MMU, too, in nearly (?) all cases when you can _simply_ (without
any other code change) replace fork() with vfork() anyway. )
Yes, pretty much true...
But userland software I all over the place see funn
especially if there is any question over the safe use of vfork.
Of course there are lots of cases where you can't just replace fork()
and vfork(). But here you need a decent porting if you want to take care
of the "EMBED" define. In other cases (the more common ones) it would be
"nice" jus
Jivin Michael Schnell lays it down ...
>
> >>(Which IMHO in many cases seems silly, as AFAIK, you can happily use
> >>vfork() if there is
> >>an MMU, too, in nearly (?) all cases when you can _simply_ (without
> >>any other code change) replace fork() with vfork() anyway. )
> >Yes, pretty much
OK, but what to do about already existing code
Fix the usage of it :-)
I don't dare to, as I don't see a commonly agreed strategy. _I_ would
just replace the code mentioned by p = vfork(); but I feel that we would
get bashed (and no pushing upstream) for this as traditionally ev
11 matches
Mail list logo
