Date: Mon, 6 Jul 1998 20:27:20 +0100 From: Timo Geusch <freebsd@timog.prestel.co.uk> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: PCMCIA disk cards Message-ID: <19980706202720.A785@timog.prestel.co.uk> In-Reply-To: <199807061559.IAA03530@antipodes.cdrom.com>; from Mike Smith on Mon, Jul 06, 1998 at 08:59:50AM -0700 References: <Pine.NEB.3.95.980706154230.2620A-100000@korin.warman.org.pl> <199807061559.IAA03530@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 06, 1998 at 08:59:50AM -0700, Mike Smith wrote: > > Probably. But what with inserting and removing them... I guess removing > > such a drive can panick your system. > > Yes. PCMCIA sucks. > > There are actually a couple of different ways of talking to PCCARD > memory devices. The PAO people have driver support for some PCCARD ATA > and CompactFlash devices. You should talk to Hosakawa-san > (hosakawa@freebsd.org) and ask him why he hasn't committed these bits > (he said he was going to quite a while back now...) Well, to if I remember correctly, there are at least four different ways of handling storage devices in PCMCIA: 1. SRAM cards. Used as 'normal' memory, you map a part of their memory into the infamous 'above 640k' range because the bleedin' adapter still can't handle higher addresses (Ugh) and simply read/write from that memory. 2. Flash cards that come up as flash cards. IMHO, this is the worst part of 'em# all. The problem with those cards is that you have to determine exactly what kind of card it is, to make sure you get the erase block size and stuff like that right. Apart from that, you already know that the day after you are finished your customer will show up with yet another dubios card that will not work. 3. Flash cards and Hard drives that are using the ATA interface. From a driver point of view these are amongst the easiest to support, baring the one or two really weird cards that want to be configured as either primary or secondardy IDE devices. 4. The infamous non-ATA HD. Never came across one, but they are rumored to exist in the wild. Considering the file system problems (Guess were all this blabbing came from - I used to work on a PCMCIA driver suite for Windows NT, which incidentally has similar problems), I guess it should be possible to implement a partial working kind of hot swapping with a bit of reliance on the luser. Basically, the things that need to be assured are: - No write buffering. All the data has to go directly to the device. If that device has some kind of light, one can at least tell the luser that s/he can't remove the drive while the light is on. Pity that nobody bothered to create some kind of physical locking mechanism, otherwise we could simply lock the device until its unmounted. - When a PCMCIA ATA device is present, the kernel needs to know that it can go away at any time. Thus, the handling of sudden disk removals should be implemented in a way that will actually prevent the kernel from panicking. - Hot insertion would be nice, too :). Should not be to complicated, though. I actually did not look at the code for a long time, so if some of the features are already present, I have to apologize. Cheers, Timo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980706202720.A785>