.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "PDCSPATH_HWPATH_WRITE" "9" "09 October 2005" "" ""

.SH NAME
pdcspath_hwpath_write \- This function handles hardware path modifying.
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
ssize_t pdcspath_hwpath_write  (struct pdcspath_entry * \fIentry\fB, const char * \fIbuf\fB, size_t \fIcount\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIentry\fB\fR
An allocated and populated pdscpath_entry struct.
.TP
\fB\fIbuf\fB\fR
The input buffer to read from.
.TP
\fB\fIcount\fB\fR
The number of bytes to be read.
.SH "DESCRIPTION"
.PP
We will call this function to change the current hardware path.
Hardware paths are to be given '/'-delimited, without brackets.
We take care to make sure that the provided path actually maps to an existing
device, BUT nothing would prevent some foolish user to set the path to some
PCI bridge or even a CPU...
A better work around would be to make sure we are at the end of a device tree
for instance, but it would be IMHO beyond the simple scope of that driver.
The aim is to provide a facility. Data correctness is left to userland.