DEVFS_FL_AUTO_DEVNUM on block devices

DEVFS_FL_AUTO_DEVNUM on block devices

[Taral]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

I'm trying to write a device driver that dynamically creates block
devices (kind of like loop does). I'd like to use DEVFS_FL_AUTO_DEVNUM,
but it looks like devfs doesn't initialize the block queues in any
useful way. Does anyone have any code that I can use? If so, Cc: me on
replies. Thanks!

-- 
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: DEVFS_FL_AUTO_DEVNUM on block devices

[Richard Gooch]

taral@taral.net writes:
> 
> --HlL+5n6rz5pIUxbD
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

Please fix your mailer to not send this junk.

> I'm trying to write a device driver that dynamically creates block
> devices (kind of like loop does). I'd like to use DEVFS_FL_AUTO_DEVNUM,
> but it looks like devfs doesn't initialize the block queues in any
> useful way. Does anyone have any code that I can use? If so, Cc: me on
> replies. Thanks!

Devfs isn't supposed to manage your block queues. That's not what it's
designed for. Devfs is just a way of managing your device nodes.

Block queue management can be done by the "generic" block I/O layer
(or you can write your own management code, but that's not
practical). This layer requires that you have a major number for your
driver, so that certain information can be shoved into some static
arrays (yes, it's butt-ugly, and it will change in 2.5).

You can use the devfs_alloc_major() function to grab a major number
that won't conflict with another driver. Then use that major when
calling devfs_register().

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: DEVFS_FL_AUTO_DEVNUM on block devices

[Taral]

On Tue, Sep 04, 2001 at 02:13:34PM -0600, Richard Gooch wrote:
> taral@taral.net writes:
> > 
> > --HlL+5n6rz5pIUxbD
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> 
> Please fix your mailer to not send this junk.

It's not junk, it's PGP/MIME. But I disabled it for you.

> You can use the devfs_alloc_major() function to grab a major number
> that won't conflict with another driver. Then use that major when
> calling devfs_register().

Sounds good to me. It might be wise, however, to disable use of
DEVFS_FL_AUTO_DEVNUM in devfs_register with block devices, since it's
not incredibly useful to have two different drivers sharing a major
number.

-- 
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose

Re: DEVFS_FL_AUTO_DEVNUM on block devices

[Richard Gooch]

taral@taral.net writes:
> On Tue, Sep 04, 2001 at 02:13:34PM -0600, Richard Gooch wrote:
> > taral@taral.net writes:
> > > 
> > > --HlL+5n6rz5pIUxbD
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > 
> > Please fix your mailer to not send this junk.
> 
> It's not junk, it's PGP/MIME.

"One man's junk is another man's treasure" :-)

> But I disabled it for you.

Thanks. It just gets in the way. And I'm tired of what I consider
pollution on the 'net. With horror I consider MIME+HTML+vcard. Next I
suppose we'll have M$ "active email" which requires a full virtual
machine in which to execute. <shudder>

> > You can use the devfs_alloc_major() function to grab a major number
> > that won't conflict with another driver. Then use that major when
> > calling devfs_register().
> 
> Sounds good to me. It might be wise, however, to disable use of
> DEVFS_FL_AUTO_DEVNUM in devfs_register with block devices, since
> it's not incredibly useful to have two different drivers sharing a
> major number.

That's a policy decision, and I don't want to make that. Also
consider that with the block I/O rewrite planned for 2.5, we'll do
away with these abominable arrays, and thus DEVFS_FL_AUTO_DEVNUM makes
plenty of sense even for block devices. It will in fact be the
preferred way of doing things (at least for devfs).

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca