Re: [linuxdc-dev] VMU driver (Better maple)

[Fredrik H. <hu...@hu...>]

Any complaints about the new maple stuff so far?
I've started reading up on block and mtd devices,
and it seems to me that the mtd subsystem really
isn't very well suited for writing a VMU driver.

In particular, the mtd subsystem seems to use driver api
which writes one byte at a time, which is something
I would really really like to avoid in a VMU driver.

In my oppinion it would seem better to use a block device
driver, but this may have other traps of course.
One particular issue with a VMU driver is that it needs
to convey some meta-information (size, block size, root
block location etc.) to the reader/filesystem. One way
to support this would be to use an ioctl, but I'm not sure
that would be the best way because then loopbacks would
be impossible once a VMU filesystem is written.....

An alternative solution (which is not pretty, but it works)
would be to map the meta-information into block 0 and then
map block 0 of the VMU into block 1 of the block device
(etc. etc.).

And, before I forget: If I do make a vmu driver, what major/minor
numbers should I use? In theory you can connect 24 vmus to a
dreamcast, so I'll need at least 24 separate devices. (Alternatively,
I could create *one* device node which maps all the vmus into one
address space, but I would only do that as a last resort...)

What do you people think? Since I'm fairly new to linux kernel
hacking I apreciate your input on these ideas.

        /Hubbe