Kevin Lawton <[EMAIL PROTECTED]> wrote:
> I don't user the minor number yet, but we could split the
> FreeMWare major number into various channels, which could
> be fopen()'d. Maybe one for the memory space, etc.
>
> Once we solidify on the major/minor number issues, we should
> file for an official FreeMWare major number. Somewhere in
> my kernel book it gives the place to do that.
We might even be able to get by with just a single major/minor
combination (which will probably make it easier to get an official
number allocated ;-/). I'd originally thought we'd use the minor
numbers to differentiate between multiple VM boxes open at the
same time. This might prove to be unnecessary after all: we
can simply associate a particular VM with a file *handle*.
This way, if two processes open /dev/freemware twice, they get
two boxes. If, however, we want two processes to access the same
box, one must open the device, and pass the file handle on to the
other process, either via fork(), or by passing the handle over a
socket. (This is how shared private mmap()'s are implemented on
many Unixes ...)
As to the operations made available to user space: the obvious
read/write/mmap implementation would be to offer access to the
physical memory image. So the user process would simply write()
to some offset to initialize the physical memory; or even simpler
it would mmap() the memory into its own address space. Everything
else should be done via ioctl()s.
I'll try whether I can get read/write/mmap to the VM memory working
under Linux ...
> I'm up for some suggested guidelines. It might make things go
> more smoothly. Keep in mind though this is code by anarchy, so
> we shouldn't push any hard rules. The incentive to not having
> any hard rules is that you have more incentive to write more code,
> because then it's exactly to your liking. :^)
I agree. Too many rules are probably not really helpful ...
Bye,
Ulrich
