On Thu, 19 Apr 2007, Martin Rosenau wrote:
Or keep the code in the ufs driver and add a mount option to do this
(call it "liliput" or whatever)
There are three possibilities:
1) Writing all the code only once - this makes the UFS slower because the
"if(must_swap_byte)" condition costs time. The code size increses a bit.
Why does it make it slower ?
You would, if you chose to go this way, detect the filesystem's endianness
at mount time, and simply use a different set of metadata access functions
(the C equivalent of "virtual methods") for accessing the on-disk
metadata.
Since on-disk access is slow anyway, whether you call through a function
pointer or directly really doesn't matter at all.
2) Writing all the code twice in the UFS driver - this makes the driver twice
as large which costs a lot of RAM.
Not all code. Very little code, in fact. Just the stuff that gets/puts
metadata from/to disk.
3) Writing two drivers "ufs" and "ufsx86/ufssparc" - I think this is the best variant. It
does not touch the "ufs" driver; I only load the kernel module when I want to transfer data using
an USB device or similar from Sparc to x86 and vice versa or read old Sparc HDs on my x86 PC ...
I'm inclined to agree with you that the existing UFS driver shouldn't be
touched for this. At least not till the new driver has proven itself and
is sufficiently feature-par with existing UFS. There are a lot of non-ON
projects and even 3rd-party drivers that somehow hook into our current UFS
and make either assumptions about its behaviour or even directly call
functions from it (SunCluster PXFS or AFS are just two examples), so the
thought of eventually replacing it will need to be deferred for a while
yet.
But why two drivers ? They'd share a huge amount of code. We used to have
two "sd" drivers, one for Solaris/sparc and one for Solaris/x86; they
shared a common ancestry, and we re-merged them for Solaris 9 (I think).
Because, even after around 10 years of being split, they still shared
around 80% of the code, and maintenance (fixing a problem in both drivers
and/or providing an enhancement in both drivers) had become quite
cumbersome. So history tells us doing this is a bad idea. I do not second
the belief that history is bound to repeat itself, but that's just me :)
Btw, regarding the other question on lofi and partition tables, see:
http://bugs.opensolaris.org/view_bug.do?bug_id=4765069
The idea isn't that new. There's a lot in the internal comments section of
this bug, I will contact the people who put updates in there and ask
whether that needs to be internal - the discussion on that should become
visible, I think ... please wait a few days ...
FrankH.
Martin
This message posted from opensolaris.org
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org
