Minors remaining in Major 10 ??

Minors remaining in Major 10 ??

[Andre Hedrick]

HPA,

Thoughts on granting all block subsystems a general access misc-char minor
to do special service access that can not be down to a given device if it
is open.  There are some things you can not do to a device if you are
using its device-point to gain entry.  Also do the grab a neighboor and
force the migration to find the desired major/minor is painful.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[H. Peter Anvin]

Andre Hedrick wrote:
> 
> HPA,
> 
> Thoughts on granting all block subsystems a general access misc-char minor
> to do special service access that can not be down to a given device if it
> is open.  There are some things you can not do to a device if you are
> using its device-point to gain entry.  Also do the grab a neighboor and
> force the migration to find the desired major/minor is painful.
> 

Hmmm... this would be better done using a dedicated major (and then minor
= block major.)  This is something we can do in 2.5 once we have the
larger dev_t; at this point, I'd be really hesitant to allocate
additional that aren't obligatory.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[Andre Hedrick]

On Sat, 20 Jan 2001, H. Peter Anvin wrote:

> Andre Hedrick wrote:
> > 
> > HPA,
> > 
> > Thoughts on granting all block subsystems a general access misc-char minor
> > to do special service access that can not be down to a given device if it
> > is open.  There are some things you can not do to a device if you are
> > using its device-point to gain entry.  Also do the grab a neighboor and
> > force the migration to find the desired major/minor is painful.
> > 
> 
> Hmmm... this would be better done using a dedicated major (and then minor
> = block major.)  This is something we can do in 2.5 once we have the
> larger dev_t; at this point, I'd be really hesitant to allocate
> additional that aren't obligatory.

Er, I did not make the point clear enough, drat.

mknod /dev/ide-service c 10 ???
mknod /dev/scsi-service c 10 ???

These would be char devices that would allow one to pass a struct to an
ioctl to do device or host services that normally have to attempted by
opening the device desired.  This fails if you are trying to unload the
driver (with KMOD enabled) so that you could switch devices or change
driver types.  Yes this is the migration to a hotswap^H^H^H^H^H^H^H
general host/device services calls.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[H. Peter Anvin]

Andre Hedrick wrote:
> 
> On Sat, 20 Jan 2001, H. Peter Anvin wrote:
> 
> > Andre Hedrick wrote:
> > >
> > > HPA,
> > >
> > > Thoughts on granting all block subsystems a general access misc-char minor
> > > to do special service access that can not be down to a given device if it
> > > is open.  There are some things you can not do to a device if you are
> > > using its device-point to gain entry.  Also do the grab a neighboor and
> > > force the migration to find the desired major/minor is painful.
> > >
> >
> > Hmmm... this would be better done using a dedicated major (and then minor
> > = block major.)  This is something we can do in 2.5 once we have the
> > larger dev_t; at this point, I'd be really hesitant to allocate
> > additional that aren't obligatory.
> 
> Er, I did not make the point clear enough, drat.
> 
> mknod /dev/ide-service c 10 ???
> mknod /dev/scsi-service c 10 ???
> 
> These would be char devices that would allow one to pass a struct to an
> ioctl to do device or host services that normally have to attempted by
> opening the device desired.  This fails if you are trying to unload the
> driver (with KMOD enabled) so that you could switch devices or change
> driver types.  Yes this is the migration to a hotswap^H^H^H^H^H^H^H
> general host/device services calls.
> 

No, I think I understood perfectly well.  I said that if it's going to be
bound to each block device subsystem it would make more sense to
establish that tie explicitly -- if that isn't possible I'm a bit
confused.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[Andre Hedrick]

On Sat, 20 Jan 2001, H. Peter Anvin wrote:

> Andre Hedrick wrote:
> > 
> > On Sat, 20 Jan 2001, H. Peter Anvin wrote:
> > 
> > > Andre Hedrick wrote:
> > > >
> > > > HPA,
> > > >
> > > > Thoughts on granting all block subsystems a general access misc-char minor
> > > > to do special service access that can not be down to a given device if it
> > > > is open.  There are some things you can not do to a device if you are
> > > > using its device-point to gain entry.  Also do the grab a neighboor and
> > > > force the migration to find the desired major/minor is painful.
> > > >
> > >
> > > Hmmm... this would be better done using a dedicated major (and then minor
> > > = block major.)  This is something we can do in 2.5 once we have the
> > > larger dev_t; at this point, I'd be really hesitant to allocate
> > > additional that aren't obligatory.
> > 
> > Er, I did not make the point clear enough, drat.
> > 
> > mknod /dev/ide-service c 10 ???
> > mknod /dev/scsi-service c 10 ???
> > 
> > These would be char devices that would allow one to pass a struct to an
> > ioctl to do device or host services that normally have to attempted by
> > opening the device desired.  This fails if you are trying to unload the
> > driver (with KMOD enabled) so that you could switch devices or change
> > driver types.  Yes this is the migration to a hotswap^H^H^H^H^H^H^H
> > general host/device services calls.
> > 
> 
> No, I think I understood perfectly well.  I said that if it's going to be
> bound to each block device subsystem it would make more sense to
> establish that tie explicitly -- if that isn't possible I'm a bit
> confused.

Okay, I am definitely not clear because I am leading the wrong direction.
A single char-device would access all of ATA or all of SCSI.

Seek by a number of known things by the running kernel to find and select
the needed host/device by a passive method.
	host[I]
	interrupt[J]
	iobases[K]
	lun_index[L]
	memmaps[M]
or
	direct MAJOR|MINOR

The idea is to have a char not a block because there is no buffered access
to the dummy driver.  It is very painful to have to open one block device
and pass parameters to select the one you really want to service in a
passive mode.

However, this looks like a case for another phone call because I am not
able to explain it in email the way it needs to be explained :-((

Somebody please write a book, 'Communication for DUMMIES' please.

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[Jens Axboe]

On Sat, Jan 20 2001, Andre Hedrick wrote:
> The idea is to have a char not a block because there is no buffered access
> to the dummy driver.  It is very painful to have to open one block device
> and pass parameters to select the one you really want to service in a
> passive mode.

Like the raw devices we have already?

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[Andre Hedrick]

On Sat, 20 Jan 2001, H. Peter Anvin wrote:

> Andre Hedrick wrote:
> > >
> > > No, I think I understood perfectly well.  I said that if it's going to be
> > > bound to each block device subsystem it would make more sense to
> > > establish that tie explicitly -- if that isn't possible I'm a bit
> > > confused.
> > 
> > Okay, I am definitely not clear because I am leading the wrong direction.
> > A single char-device would access all of ATA or all of SCSI.
> > 
> 
> That's fine.  ATA and SCSI are a bit special because they have multiple
> majors -- something that I hope we can get rid of with the dev_t
> expansion anyway, but I think the principle still holds.

Hi Peter,

Regardless if we rip out the entire rule of majors for dev_t, will there
be a service dummy driver to various block-devices?  There is a real need
for this if we are going to get full control of the hardware by indirect
access obtain the functionality that I see and need in the near future.

I want to use KMOD to an advantage.

Assume removable device bays such that you can swap in any and every kind
of ata-atapi device and/or all scsi-devices, one needs to have a way to
tell the driver to do things that are not native to its general mode of
operations as of today.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[H. Peter Anvin]

Andre Hedrick wrote:
> 
> Hi Peter,
> 
> Regardless if we rip out the entire rule of majors for dev_t, will there
> be a service dummy driver to various block-devices?  There is a real need
> for this if we are going to get full control of the hardware by indirect
> access obtain the functionality that I see and need in the near future.
> 

At this point, I'll allocate a device number when someone is ready to
release a driver - no sooner.  There simply is not a whole lot of choice
because of the extreme shortage of device numbers that's going to last us
until dev_t gets expanded.

	-hpad


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Minors remaining in Major 10 ??

[Andre Hedrick]

On Sat, 20 Jan 2001, H. Peter Anvin wrote:

> Andre Hedrick wrote:
> > 
> > Hi Peter,
> > 
> > Regardless if we rip out the entire rule of majors for dev_t, will there
> > be a service dummy driver to various block-devices?  There is a real need
> > for this if we are going to get full control of the hardware by indirect
> > access obtain the functionality that I see and need in the near future.
> > 
> 
> At this point, I'll allocate a device number when someone is ready to
> release a driver - no sooner.  There simply is not a whole lot of choice
> because of the extreme shortage of device numbers that's going to last us
> until dev_t gets expanded.

Cool Peter!

Will finish the code hack and clean it up in the next three days or so...  
It is only an idea to test and you can see it in action first.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/