From: Joe deBlaquiere (joe@wirespeed.com)
Date: Wed Jul 19 2000 - 16:17:21 EDT
In order to access stuff from user space you have to mmap() the space. I can see there could be some problems with mmap(). I don't think it would be impossible to leave some bread crumbs around that would allow you to fix the SP/FP stuff at the point of the fork(). As far as the souped up car story goes, no need to repeat that to me. I know that one first hand ;o). But I have to say it was more fun along the way. Additionally, we're talking about trading off development time for harware cost. If I was gonna build a go-zillion of something, I'd think about writing a lot of software to save $1/unit... > -----Original Message----- > From: Geoffrey Wossum [mailto:gpw0341@omega.uta.edu] > Sent: Wednesday, July 19, 2000 11:59 AM > To: joe@wirespeed.com > Cc: uclinux@c3po.kc-inc.net; "Uclinux-Dev (E-mail)" > Subject: Re: [UCLINUX] Old kernel, old argument, new (maybe) point(s) > > > > 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!). > > Although arguably a bad thing to do from user space, > accessing hardware > registers from user space is not, and will never be, > forbidden. X servers > access video hardware from userspace. Although maybe they have to do > something to map it, some system call? > > Maybe that's how to get around this. Force userspace > register access to > go through peek()/poke() functions (ahh, BASIC!), or use a hwmap() > function to get a mapped pointer to the register. I think most people > could live with this solution most of the time. > > And if you could have a compiler switch to turn on/off the > redirection, in > case you didn't need fork() (this would slow stuff down), or wanted > old-style hardware access, then most people would be happy all of the > time. > > I'm not sure 'ez328's have enough power to perform all these software > relocations though. Even the stack would have to be offset, > unless you > could gurantee the compiler would never push stack pointers onto the > stack. Hmm, you can't. The frame pointers are based on the stack > pointer, and you can return from functions that call fork(), > so all of the > frame pointers would be pointing to the old processes stack, > so you would > have to offset even the stack accesses. You couldn't just modify sp > on fork() and have it work. Ouch! Maybe it would be worth it on a > Coldfire. Plus fork() itself would have a huge penalty since > you would > have to copy everything at the time of the fork(). > > I think if you really need fork(), uClinux maybe the wrong platform. > Remeber, Windows programmers live quite happily without > fork(). Well, as > happily as a Windows programmer can live. > > I remember way back in the history of this list somebody, I > think it was > D. Jeff Dionne, had a story about a cheap car he had souped > up. The basic > point of the story was that he had gotten a cheap car, made a lot of > modifications to it, and ended up probably spending more > money than if he > had gotten a car that way from the factory, and the car > probably wasn't as > good as a factory car. That story seems to apply here. > Maybe it should > be posted again. > > --- > 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