This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ECOS] load data from floppy


Gary Thomas <gary@mlbassoc.com> writes:

> On Wed, 2003-07-30 at 04:36, Nick Garnett wrote:
> > davidw@dedasys.com (David N. Welton) writes:
> > 
> > > Nick Garnett <nickg@ecoscentric.com> writes:
> > > 
> > > > > I'm having a go at making a floppy driver, but it doesn't appear
> > > > > to be particularly simple:-/
> > > 
> > > > I seem to recall that the PC floppy hardware is really nasty to
> > > > program. IDE is a doddle by comparison.
> > > 
> > > You're right.  It's a very unpleasant interface.
> > > 
> > > I managed to beat the relevant Minix code into shape to do what I
> > > need.  Would this be of any interest to you guys?  I'm sure it needs
> > > an expert hand to really bring it up to snuff, but it does work for
> > > reading a floppy.  The license is the new BSD-style Minix license.
> > > 
> > 
> > It would certainly be worth looking at. We also need to make sure that
> > way you are using it matches with the (currently very vague) ideas I
> > have about how block devices should work. There are also issues of
> > packaging, configuration and coding style to worry about.
> > 
> 
> Are any of these ideas written down?  I ask, in particular, because
> I may wish to implement some block I/O devices (and associated file
> systems) soon and I'd like to keep my approach in line with you.
> 

Nothing written I'm afraid. The main thing is the question of
addressing and transfer unit granularity. It's tempting to treat a
block device like a file and address and transfer on byte
granularity. But we need to deal with multi-GB drives, so that won't
work if we use a 32 bit offset. My intention was to work in 512 byte
sectors, giving a limit of 2TB for any single block device. I think
that should be adequate for most embedded needs.

An alternative approach is to negotiate these parameters between the
filesystem and driver. But I would prefer to keep things simple.

If you are going to do some filesystem work then we should make some
effort to coordinate things. We have already had a submission of a
simple FAT16 filesystem implementation, I have been working on a full
VFAT32 filesystem in spare moments (which have been few and far
between, so there has not been much progress), and I know that there
have been other efforts to port GPL code. If we are not careful we
will end up with several parallel efforts, and various annoyed
people.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]