public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Savin Zlobec <savin@elatec.si>
To: Alexander.Neundorf@jenoptik.com, andrew@lunn.ch
Cc: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: fatfs and io disk misc patches
Date: Fri, 09 Jul 2004 11:39:00 -0000	[thread overview]
Message-ID: <40EE83F0.40609@elatec.si> (raw)

Alexander Neundorf wrote:

> <>> > Since people are starting to use it and doing ports, it would be
> > > wise to specify how all of the disk subsystem should look and what
> > > features should be supported before it gets harder and harder to
> > > change anything generic.
> > >
> > > Now it is the time for users to post their comments,
> > feelings, wishes...
> >
> > Not many comments :-(
>
> Ok, wishes come here :-) :
> Faster cf access by checking for adjacent sectors, support for 
> exchanging the cf card while<> ecos is running (or does it actually 
> work and I was too stupid ?), long file names, fat32.


In my spare moments I did (doing) some refactoring on fatfs. File access 
is faster, reduced memory usage,
saner code, kernel dependencies are gone, some traces of malloc left, 
but shouldn't last long (maybe I'll make
an CDL option for that). After that I may go for the generic ATA low 
level driver...

Hot exchanging the CF actually works - the disk_(dis)connected callbacks 
are intended for that, they trigger
(in)validation of device handlers and MBR scanning. They are indended to 
be called from the low level driver
which should detect the CF insertion/removal - or a pair of keys could 
be defined for cyg_io_set_config which
would do this in disk_set_config. One may face the problem of unmounting 
the fatfs after the CF was removed...
for this we would need an additional flag field in umount fn to specify 
an forced unmount, or it could be specified
with fs_get/set_config.

About the adjacent sectors, long file names and fat32 - I wouldn't mind 
having that - any volunteers ?

savin

 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

             reply	other threads:[~2004-07-09 11:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-09 11:39 Savin Zlobec [this message]
     [not found] <40DA9B63.9000200@elatec.si>
     [not found] ` <20040629163314.GH5877@lunn.ch>
     [not found]   ` <40E3DBF9.1060107@elatec.si>
     [not found]     ` <20040701103046.GB11101@lunn.ch>
     [not found]       ` <40E3F0FE.4070306@elatec.si>
     [not found]         ` <20040701130635.GD11101@lunn.ch>
     [not found]           ` <40E51E5D.8050708@elatec.si>
     [not found]             ` <20040702091532.GH11101@lunn.ch>
2004-07-02 12:44               ` Savin Zlobec
2004-07-08 10:30                 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40EE83F0.40609@elatec.si \
    --to=savin@elatec.si \
    --cc=Alexander.Neundorf@jenoptik.com \
    --cc=andrew@lunn.ch \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).