Re: [ECOS] Renaiming disk devices....

[Jonathan Larmour <jifl at eCosCentric dot com>]

Frank Pagliughi wrote:
> Jonathan Larmour wrote:
>> Andrew Lunn wrote:
>>  
>>> Hi Folks
>>>
>>> A while back Frank Pagliughi provided a patch for the IDE driver which
>>> amongst other things renamed the disk drives. The change would be
>>>
>>> /dev/hda -> /dev/disk0
>>> /dev/hdb -> /dev/disk1
>>> etc
>>>
>>> This makes the IDE driver consistent with the FATFS packages which
>>> also uses the same naming convention. The "Elatec v850 development
>>> board disk driver" also uses this naming scheme. However the MMC disk,
>>> synthetic disk and fileio package documentation use the /dev/hd
>>> scheme.
>>>
>>> Overall we are not consistent. We could:
>>>
>>> 1) leave it all as it is.
>>> 2) make it consistent, changing to:
>>>    a) /dev/hd?
>>>    or
>>>    b) /dev/disk?       
>>
>>  
>>> Changing will probably lead to some short term breakage as with any
>>> renaming of objects, but in the long term consistency is always good.
>>>
>>> I would suggest making the change to /dev/disk everywhere, but what do
>>> others think?
>>>     
>>
>> I think the best situation is to have each name for each device driver
>> class be unique, otherwise by default they can't co-exist.
>>
>> So maybe you could say /dev/hda should be /dev/idedisk0 or something like
>> that (just /dev/ide0 could refer to a bus instance, rather than disk).
>> Although I think possibly these days it's well enough accepted that
>> /dev/hda refers to an IDE disk (like /dev/sda refers to a SCSI disk) that
>> it could probably be left as-is.
>>
>> The other disks should probably be renamed to something unique though
>> IMHO,
>> e.g. /dev/synthdisk0, /dev/mmcspi0
>>
>> Jifl
>>   
> I can see that. My assumption was that individual embedded systems
> wouldn't have a lot of different types of disk drives, so a simplified
> naming scheme would be easier to understand. But, then again, nothing
> would surprise me, so I could easily be convinced either way.

True for something board-specific, but with things like media via card
interfaces, or via SPI, or plug-in PCI bus, I think it's safer just to make
sure they can't clash.

> It's just unfortunate that  a configuration with a single filesystem and
> single drive type don't agree on the drive name. Is this something the
> CDL could detect and resolve?

Not easily. A single filesystem isn't guaranteed after all. Theoretically
we could have some nominal "default" but CDL doesn't really have an idea of
"here are some possibilities, just pick any one", not without having a
conflict for the user to resolve anyway. And it's not clear what would be
sensible to do with a "default" FS, as opposed to any other.

> My thoughts came about because, even though I have a reasonable amount
> of experience with eCos, the first time I tried to experiment with using
> a hard drive and FAT file system, I was much delayed in a debug session,
> only to discover the sole problem was due to the naming scheme:
> 1. The only test program, fatfs1, is hard-coded for drives named
> "/dev/diskx/"
> 2. The drive name must end with a "/" in order for the lookup to
> discover partitions.
> 
> Maybe we just need it documented better.

If CDL were better integrated with TCL (very much on the wishlist) we could
enforce that restriction. Until then, documentation will have to do.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

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