IDE ioctl documentation & a new ioctl

IDE ioctl documentation & a new ioctl

[Edward Falk]

Hi all; let me introduce myself:  I'm the guy that does IDE sustaining 
for Google.

I'm getting ready to sit down and document the IDE ioctls.  Probably 
Documentation/hdio.txt or something like that.  Before I start though, 
is anybody already doing this?

And while I'm on the subject, we're getting ready to write a new hdio 
ioctl, an extension of HDIO_DRIVE_CMD.  The intent here is to be 
slightly more general-purpose than HDIO_DRIVE_CMD, with an eye to 
supporting the full set of SMART functionality.  Current plan is to have 
the user pass a struct containing a pointer to the argument list, a 
pointer to the data buffer, and a data buffer length value.  Consider 
this a design document; any comments and/or feature requests?

	-ed falk
	efalk@google.com

Re: IDE ioctl documentation & a new ioctl

[Jim Nelson]

Edward Falk wrote:
> Hi all; let me introduce myself:  I'm the guy that does IDE sustaining 
> for Google.
> 
> I'm getting ready to sit down and document the IDE ioctls.  Probably 
> Documentation/hdio.txt or something like that.  Before I start though, 
> is anybody already doing this?
> 

No one that I know of.  I had a thought in the back of my head of tackling ioctl 
documentation after I went through the stuff that's already in Documentation, but 
I figured I had enough to chew on for right now.

I'd probably make a subdirectory - i. e. Documentation/ioctl/hdio.txt - to 
differentiate it from other documents, and make it easier to get maintainers to 
put some stuff in there. ;)   AFAICT, there is next to no documentation on ioctl's 
anywhere in the kernel tarball.

> And while I'm on the subject, we're getting ready to write a new hdio 
> ioctl, an extension of HDIO_DRIVE_CMD.  The intent here is to be 
> slightly more general-purpose than HDIO_DRIVE_CMD, with an eye to 
> supporting the full set of SMART functionality.  Current plan is to have 
> the user pass a struct containing a pointer to the argument list, a 
> pointer to the data buffer, and a data buffer length value.  Consider 
> this a design document; any comments and/or feature requests?
> 
>     -ed falk
>     efalk@google.com
> -

Re: IDE ioctl documentation & a new ioctl

[Jeff Garzik]

Edward Falk wrote:
> And while I'm on the subject, we're getting ready to write a new hdio 
> ioctl, an extension of HDIO_DRIVE_CMD.  The intent here is to be 
> slightly more general-purpose than HDIO_DRIVE_CMD, with an eye to 
> supporting the full set of SMART functionality.  Current plan is to have 
> the user pass a struct containing a pointer to the argument list, a 
> pointer to the data buffer, and a data buffer length value.  Consider 
> this a design document; any comments and/or feature requests?

HDIO_DRIVE_TASK and flagged taskfiles should cover everything you need.

	Jeff

Re: IDE ioctl documentation & a new ioctl

[Edward Falk]

> I'd probably make a subdirectory - i. e. Documentation/ioctl/hdio.txt - 
> to differentiate it from other documents, and make it easier to get 
> maintainers to put some stuff in there. ;)   AFAICT, there is next to no 
> documentation on ioctl's anywhere in the kernel tarball.

Good point; the existance of an ioctl subdirectory would encourage 
others to write documentation as well.

Re: IDE ioctl documentation & a new ioctl

[Edward Falk]

> HDIO_DRIVE_TASK and flagged taskfiles should cover everything you need.

I'll take another look.  Thanks.

	-ed falk

Re: IDE ioctl documentation & a new ioctl

[Bartlomiej Zolnierkiewicz]

Hi!

Documenting existing ioctls would be appreciated by many people...

On Thu, 18 Nov 2004 23:07:55 -0500, Jeff Garzik <jgarzik@pobox.com> wrote:
> Edward Falk wrote:
> > And while I'm on the subject, we're getting ready to write a new hdio
> > ioctl, an extension of HDIO_DRIVE_CMD.  The intent here is to be
> > slightly more general-purpose than HDIO_DRIVE_CMD, with an eye to
> > supporting the full set of SMART functionality.  Current plan is to have
> > the user pass a struct containing a pointer to the argument list, a
> > pointer to the data buffer, and a data buffer length value.  Consider
> > this a design document; any comments and/or feature requests?
> 
> HDIO_DRIVE_TASK and flagged taskfiles should cover everything you need.

HDIO_DRIVE_TASKFILE for (flagged) taskfiles and commands requiring
data transfers.

Bartlomiej