linuxdc-dev

[linuxdc-dev] Admitting defeat

[Adrian M. <ad...@mc...>]

Well, my vmublk saves a whole 1.25k in the compiled zImage kernel, so I 
suppose that hardly justifies using it (though my nick does indicate that I 
used to write programs for a machine with 1K of RAM :->).

Bear with me and I'll remove it in the next few days.

Adrian

Re: [linuxdc-dev] Admitting defeat

[Adrian M. <ad...@mc...>]

On Thursday 19 Sep 2002 10:45 pm, Adrian McMenamin wrote:
> Well, my vmublk saves a whole 1.25k in the compiled zImage kernel, so I
> suppose that hardly justifies using it (though my nick does indicate that I
> used to write programs for a machine with 1K of RAM :->).
>
> Bear with me and I'll remove it in the next few days.
>
Made a slight mess of this with the cvs (though successfully deleted the files 
- or kicked them into the attic).

I have created a sf project called vmublk in case I need to mess about with 
these files in the future - unlikely, but I wanted to keep the option without 
having to poke about in the main linuxdc cvs.

Okay, now for the filesystem!

Adrian

Re: [linuxdc-dev] Admitting defeat

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Fri, Sep 20, 2002:

>=20
> I have created a sf project called vmublk in case I need to mess about wi=
th=20
> these files in the future - unlikely, but I wanted to keep the option wit=
hout=20
> having to poke about in the main linuxdc cvs.
>=20

Heh, well, since all of this is development code, you could've:

a) left in vmublk in the HEAD trunk, and just provided alternate Config.in
   options to select your impl. vs. mtdblock,

b) or, just create your own branch (sth. like "vmublk-testing") and do
   development there.  Paul or myself can help you out with that if you
   want.

> Okay, now for the filesystem!
>=20

I'm looking forward to your results (as I'm sure everyone else is).

M. R.

Re: [linuxdc-dev] Admitting defeat

[Adrian M. <ad...@mc...>]

On Friday 20 Sep 2002 9:44 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Fri, Sep 20, 2002:
> > I have created a sf project called vmublk in case I need to mess about
> > with these files in the future - unlikely, but I wanted to keep the
> > option without having to poke about in the main linuxdc cvs.
>
> Heh, well, since all of this is development code, you could've:
>
> a) left in vmublk in the HEAD trunk, and just provided alternate Config.in
>    options to select your impl. vs. mtdblock,
>
Well, that would be quite easy, I suppose. But I can see no real reason (at 
present) to use my implementation.

> b) or, just create your own branch (sth. like "vmublk-testing") and do
>    development there.  Paul or myself can help you out with that if you
>    want.

Well, I suppose I could do that - tell me how.

>
> > Okay, now for the filesystem!
>
> I'm looking forward to your results (as I'm sure everyone else is).
>
So am I!

I have a problem though - as I have just posted on irc....
<zx80user> I've started work on the fs now. But I have one problem.... how to 
set a magic number
<zx80user> I can find no guide to this on net at all
<zx80user> and the vmu doesn't appear to really have a native one either
<zx80user> <presumably because it's not really designed to be mounted by a 
linux vfs driver :-) >

Anybody here know the answer to this? Do I have to bother one of the 
uberhackers on lkml (scary!)?



> M. R.

Adrian