From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25025 invoked by alias); 9 Jul 2004 11:39:37 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 25017 invoked from network); 9 Jul 2004 11:39:35 -0000 Received: from unknown (HELO lorien.elatec.si) (193.77.58.106) by sourceware.org with SMTP; 9 Jul 2004 11:39:35 -0000 Received: from [10.0.0.253] (onix [10.0.0.253]) by lorien.elatec.si (8.11.6/8.11.6) with ESMTP id i69Bgci18313; Fri, 9 Jul 2004 13:42:46 +0200 Message-ID: <40EE83F0.40609@elatec.si> Date: Fri, 09 Jul 2004 11:39:00 -0000 From: Savin Zlobec User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) MIME-Version: 1.0 To: Alexander.Neundorf@jenoptik.com, andrew@lunn.ch CC: ecos-discuss@sources.redhat.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ECOS] Re: fatfs and io disk misc patches X-SW-Source: 2004-07/txt/msg00129.txt.bz2 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