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
[email protected]
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
> [email protected]
> -
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
> 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.
> HDIO_DRIVE_TASK and flagged taskfiles should cover everything you need.
I'll take another look. Thanks.
-ed falk
Hi!
Documenting existing ioctls would be appreciated by many people...
On Thu, 18 Nov 2004 23:07:55 -0500, Jeff Garzik <[email protected]> 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