mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-18 10:35:55 +00:00
3e425b968d
This code will be turned on with the TWO options DEVFS and SLICE. (see LINT) Two labels PRE_DEVFS_SLICE and POST_DEVFS_SLICE will deliniate these changes. /dev will be automatically mounted by init (thanks phk) on bootup. See /sys/dev/slice/slice.4 for more info. All code should act the same without these options enabled. Mike Smith, Poul Henning Kamp, Soeren, and a few dozen others This code does not support the following: bad144 handling. Persistance. (My head is still hurting from the last time we discussed this) ATAPI flopies are not handled by the SLICE code yet. When this code is running, all major numbers are arbitrary and COULD be dynamically assigned. (this is not done, for POLA only) Minor numbers for disk slices ARE arbitray and dynamically assigned.
125 lines
3.7 KiB
Plaintext
125 lines
3.7 KiB
Plaintext
Original notes on how this might be implememented.. may not reflect
|
|
the final code very much.
|
|
======================================================[JRE]
|
|
|
|
the slices are 'kinda' stackable..
|
|
With alternating layers of handler(driver)/slice/handler/slice/handler/slice
|
|
The "Slice" is a common structure shared between three pieces of code.
|
|
1/ the lower handler
|
|
2/ the upper handler
|
|
3/ the generic slice code, which implements the device nodes etc.
|
|
Each of these 3 items share a knowledge of the internal struture and
|
|
contents of the slice structure. they also know each other's published
|
|
interfaces.
|
|
|
|
Each layer is much like the previous..
|
|
Each layer has similar characteristics..
|
|
The slices are created bottom up..
|
|
i.e. the device probes, and creates a static 'slice' that is
|
|
assiciated with the device.. The static slice
|
|
can't be altered, unless the media is changed..
|
|
|
|
A translation method, which might be NULL, in which case
|
|
it is a simple case of offset addition.
|
|
Possibly the offset might be already added..
|
|
possibly this might be achieved by specifying a default method set.
|
|
|
|
Each disk slice has a structure associated with it..
|
|
When a slice is 'loaded' there must be some way of deciding if it has
|
|
a subslice structure. if it does, then that structure must
|
|
be loaded to create mode slices..
|
|
this is recursive.
|
|
|
|
The structuring must be such that it can recognise an attempt to change
|
|
higer level structuring..
|
|
This suggests a recursive 'open' count.. for open subslices.
|
|
|
|
The idea would be to pass the following operations through methods.
|
|
|
|
translation to (possibly more than one) io operation
|
|
open count passing..
|
|
interpretation of subslicing and other slicing operations.
|
|
possibly there might be permissions inherritance.
|
|
open a slice...
|
|
create a slice.. methods are supplied by the disk driver..
|
|
|
|
upward methods:
|
|
force close
|
|
|
|
identify slice type.. slice type modules each asked
|
|
to identify..
|
|
|
|
to do IO
|
|
|
|
1/ find apropriate slice (hash)
|
|
LIST_HEAD(slice_bucket, slice) hash_table[UNIT_HASH_SIZE - 1];
|
|
|
|
in the init,
|
|
for ( i = 0; i < UNIT_HASH_SIZE; i++) {
|
|
LIST_INIT(hash_table + i)
|
|
}
|
|
|
|
struct slice *minor_to_slice(unsigned int minor)
|
|
{
|
|
int hash = minor % UNIT_HASH_SIZE;
|
|
struct slice *slice;
|
|
|
|
slice = (hash_table + hash)->lh_first;
|
|
while (slice) {
|
|
if (slice->minor == minor) {
|
|
return (slice);
|
|
}
|
|
slice = slice->hashlist.le_next
|
|
}
|
|
return (NULL);
|
|
}
|
|
2/
|
|
if IO method,
|
|
do IO method..
|
|
return
|
|
check bounds
|
|
adjust offset
|
|
follow slice-parent link and loop to top
|
|
IO methods are supplied by drivers
|
|
drivers including concatination drivers etc.
|
|
|
|
concatination must be seen as a slice type
|
|
|
|
once all parts of a concatinated slice are created, then
|
|
the new 'concatinated slice' appears in the devfs.
|
|
a concatinated slice has a 'label' that identifies it's volume
|
|
and it's part (e.g. part 3 out of 5)
|
|
'slice's in ram are either Primary or slave slices in a concatinated slice..
|
|
|
|
|
|
to set up a slice call slice_add() which:
|
|
1/ If (slice type not known)
|
|
Identify the type (call all type probe routines in turn)
|
|
2/ call the succeeding type attach routine
|
|
3/ the attach routine calls slice_add() for each sub slice
|
|
The probe and attach may merge.
|
|
|
|
|
|
the type of a slice must be detirmined taking into account the type of the
|
|
parent slice.. It is conceivable that the parent slice
|
|
might TELL the slice_add() routine what to make the slice..
|
|
Possibly the parent set's a CONTEXT which might be helpful
|
|
in identifying a slice
|
|
|
|
|
|
disk:
|
|
set up Method struct:
|
|
IO points to disk strategy
|
|
set size to whole disk
|
|
set offset to 0
|
|
set context to RAW
|
|
call slice_add
|
|
|
|
|
|
slice_add()
|
|
called when we know about a slice..possibly we should fill out a slice
|
|
struct before calling it.
|
|
The slice struct is all that is needed to be able to do IO
|
|
to the slice. slice_add, will then link the slice into
|
|
the system as needed.
|