From: Joe deBlaquiere (joe@wirespeed.com)
Date: Wed Jul 19 2000 - 09:19:59 EDT
So here's how I would handle the example below...
a) hw_reg ... you can't do this on Linux and make it work, at least not in
user space. If you need to modify hardware registers, you'll have to write a
driver. I have been guilty of mashing registers directly from user mode
under uClinux myself, it's even kinda handy sometimes, but you'll have to
refrain from doing that in programs that use fork(). BTW : if we made this
environment optional (compiler switch?) you could still have programs that
did one or the other, just not both (you could even fork() and exec() a
program that could use a hardware register pointer!).
b) my_ary ... let's say it's at base+X and has the value X. If we copy and
change the base register, base+X still points to the same data.
c) my_ary_alias ... was base+X+20, value X+20, if the base moves, it
works... same as my_ary
so what's wrong with this???
> -----Original Message-----
> From: Geoffrey Wossum [mailto:gpw0341@omega.uta.edu]
> Sent: Wednesday, July 19, 2000 2:09 AM
> To: joe@wirespeed.com
> Cc: uclinux@c3po.kc-inc.net
> Subject: Re: [UCLINUX] Old kernel, old argument, new (maybe) point(s)
>
>
> > Perhaps I'm just being dense, but it seems to me that
> fork() can work. If
> > you go back and look at the original versions of unix, you
> will find that
> > they didn't have MMU support and they did do fork.
>
> As many people have pointed at, there was some primitive support in
> hardware for fork().
>
> > Of course we might do some things a little differently, but
> the basic
> > philosophy is there. They maintain a concept of 'base address' for a
> > process. In order to fork, they copy the entire process
> code, data,
> > stack ) and then update the base pointer.
>
> > BTW : clone() works absolutely perfectly. It's probably a
> more flexible call
> > than fork() anyway, but there are too many old programs
> that haven't thought
> > about being multi-threaded instead of multiprocess.
>
> fork() is implemented in mainstream Linux as a special case of clone()
> which seperates all resources from the parent. Just a sidenote.
>
> > So am I entirely off-base here? Let me know...
>
> I agree that it may seem like there is a solution. But the reasons C
> can't have a copying garbage collecter (or even a decent mark
> and sweep)
> also work against having fork() without hardware support.
> Greg mentioned
> many of these issues in his response.
>
> Here's a piece of hypothetical C code that should make the
> problem clear:
>
> main()
> {
> int *hw_reg = (int *)0xfff1742L; // hypothetical hw register
> int *my_ary = (int *)malloc(sizeof(int) * 100);
> int *my_ary_alias = my_ary + 20;
> int foobar = (some value that looks like it's derived
> from my_ary);
>
> /* already have a problem if a base register is used in
> software!
> * hw_reg points to an absolute address */
> *hw_reg = magic_value;
>
> my_ary[0] = 0;
> *my_ary_alias = 20; // equivalent to my_ary[20] = 20;
> // more stuff happens here
>
> if (fork())
> exit();
>
> // only child gets to this point in code
> /* hw_reg should still point to the same place, no base register
> * should be used! */
> *hw_reg = magic_value_2;
>
> /* some magic with base address could make this next part work,
> * but it would have screwed up the previous absolute access */
> my_ary[0] = 21;
>
> /* my_ary_alias was a derived pointer, did the pointer
> move handle
> * it correctly? */
> *my_ary_alias = 42;
>
> /* should be same value as before fork() even though it looked
> * like a derived pointer */
> printf("%d", foobar);
>
> return 0;
> }
>
> So if you try to automagically have pointer dereferences use a base
> pointer in the operation, absolute addresses will get inadverdently
> changed. I think that it might also screw up the current uClinux
> implementation of shared memory.
>
> And if you try to go in through the root pointer list and
> modify all of
> the pointers so that they point into the new memory area,
> derived pointers
> and things that just happen to look like derived pointers are
> problematic.
> Correctly handling derived pointers and ints that just look
> like derived
> pointers are mutually exclusive.
>
> ---
> Geoffrey Wossum
> gwossum@acm.org
> Project AKO - http://rover1.uta.edu/~ako
> Internet Imperialists - http://inetimperial.sourceforge.net
>
>
>
>
>
>
This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:15 EDT