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

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

Paul Mundt <pm...@MV...> writes:

> On Sat, Jan 26, 2002 at 05:15:40PM -0800, Fredrik Hubinette wrote:
> > Well, I might be reading the whole thing wrong, but as I understand
> > the code, it provides both char and block devices for each mtd device.
> > However, the mtd map handler has a byte-based interface which seems
> > like a lot of extra work to implement. This may however be incorrect.
> > I will do some more reading, but maybe someone more knowledge can save
> > me some trouble by pointing me in the right direction?
> > 
> See my previous mail regarding character/block device access..
> 
> As far as sizes are concerned.. take a look at include/linux/mtd/map.h ..
> 
>         __u8 (*read8)(struct map_info *, unsigned long);
>         __u16 (*read16)(struct map_info *, unsigned long);
> 	__u32 (*read32)(struct map_info *, unsigned long);
> 
> [snip]
> 
>         void (*write8)(struct map_info *, __u8, unsigned long);
>         void (*write16)(struct map_info *, __u16, unsigned long);
>         void (*write32)(struct map_info *, __u32, unsigned long);
> 
> So no .. in no way are you limited to 8-bit only access..

None of these functions provide access to a whole block of data though,
which is what would make most sense for a maple VMU device.

> > If this is indeed a misunderstanding on my behalf, then I will definitely
> > use the MTD subsystem since that is probably where vmus *should* be
> > integrated.
> > 
> Grab the latest MTD CVS if you really feel like it ..
> http://linux-mtd.infradead.org .. and start reading source..

I will.

> > I have looked at it. I may not understand it properly, but it seems
> > very incomplete and based on reading/writing one byte at a time, which
> > would be extremely slow. It was part of the reason I thought the mtdmap
> > API was byte-based.
> > 
> Again.. most proof of concepts aren't meant to be used for production
> environments.. I could've sworn we had this same kind of discussion regarding
> the stuff I was doing with maple..

I understand proof-of-concept. I'm just not sure I agree with the concept.

> The stuff is incomplete, but it doesn't take much to fix it.. really the
> majority of work that needs to be done (especially if you want to deal with
> your VMU the way it is) would be to look at writing a linux VMU fs
> implementation. This should be feasible as a hack of fat .. but the superblock
> won't reside at the beginning of the flash.. so that'll need some adjustment.
> 
> Regards,

Well, I'm planning on writing a user-space utility for reading/writing
vmus first. That way I can make sure I have all the details right before
I implement an actual filesystem. I need access to the actual device first
though.

        /Hubbe