Using _syscall3 to manipulate files in a driver

Using _syscall3 to manipulate files in a driver

[Jon Smirl]

I have the source code for a vendor written driver that is targeted at
2.6.9. It includes this and then proceeds to manipulate files from the
driver.

asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
asmlinkage _syscall3(int,read,int,fd,char *,buf,off_t,count)
asmlinkage _syscall3(int,open,const char *,file,int,flag,int,mode)
asmlinkage _syscall1(int,close,int,fd)

What is the simplest way to get open/close/read/write working under
2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
to get the driver working long enough to see if it is worth saving.
I'm on x86.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Using _syscall3 to manipulate files in a driver

[bert hubert]

On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
> What is the simplest way to get open/close/read/write working under
> 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
> to get the driver working long enough to see if it is worth saving.

I'm no expert, but try looking at the firmware loading code in the kernel,
it reads files, so it should contain the code you need. It may even do
exactly what you want, perhaps.

Good luck!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

Re: Using _syscall3 to manipulate files in a driver

[Paul Mundt]

On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
> I have the source code for a vendor written driver that is targeted at
> 2.6.9. It includes this and then proceeds to manipulate files from the
> driver.
> 
> asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
> asmlinkage _syscall3(int,read,int,fd,char *,buf,off_t,count)
> asmlinkage _syscall3(int,open,const char *,file,int,flag,int,mode)
> asmlinkage _syscall1(int,close,int,fd)
> 
> What is the simplest way to get open/close/read/write working under
> 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
> to get the driver working long enough to see if it is worth saving.
> I'm on x86.
> 
In-kernel syscalls were removed by f5738ceed46782aea7663d62cb6398eb05fc4ce0.
You can stub them back in if you want a quick and lame fix for the
driver, but you're better off rewriting it to behave sensibly rather than
wasting your time on vendor hacks.

Re: Using _syscall3 to manipulate files in a driver

[Jon Smirl]

On 1/1/07, Paul Mundt <lethal@linux-sh.org> wrote:
> On Sun, Dec 31, 2006 at 12:13:52PM -0500, Jon Smirl wrote:
> > I have the source code for a vendor written driver that is targeted at
> > 2.6.9. It includes this and then proceeds to manipulate files from the
> > driver.
> >
> > asmlinkage _syscall3(int,write,int,fd,const char *,buf,off_t,count)
> > asmlinkage _syscall3(int,read,int,fd,char *,buf,off_t,count)
> > asmlinkage _syscall3(int,open,const char *,file,int,flag,int,mode)
> > asmlinkage _syscall1(int,close,int,fd)
> >
> > What is the simplest way to get open/close/read/write working under
> > 2.6.20-rc2? I know this is horrible and shouldn't be done, I just want
> > to get the driver working long enough to see if it is worth saving.
> > I'm on x86.
> >
> In-kernel syscalls were removed by f5738ceed46782aea7663d62cb6398eb05fc4ce0.
> You can stub them back in if you want a quick and lame fix for the
> driver, but you're better off rewriting it to behave sensibly rather than
> wasting your time on vendor hacks.

I was able to achieve a temporary work around by manipulating 'struct
file' directly. This fixed things enough so that I could load the
driver and check it out. zd1211 wireless is a case where we have the
vendor supplying and supporting a GPL driver based on 2.6.9 that is
300K and not very integrated into the networking code.  Then there is
the zd1211rw project, 85K, which is in the kernel source and is a
rework of the vendor code by non-vendor developers, It is integrated
with the Linux networking internals.

The problem is that the vendor driver can do some things that the
zd1211rw version can't. I'm trying to figure out why some things are
working the vendor driver that fail in zd1211rw.

@@ -8684,7 +8691,8 @@ #endif		



 void zd1205_load_card_setting(struct zd1205_private *macp, u8 bInit)

 {

-	int ifp;

+	struct file *filp = NULL;

 	int bcount = 0;

 	mm_segment_t fs;

 	unsigned int file_length;

@@ -8705,12 +8713,17 @@ void zd1205_load_card_setting(struct zd1
 	set_fs(KERNEL_DS);



 	// open the file with the firmware for uploading

-	if (ifp = open(config_filename, O_RDONLY, 0 ), ifp < 0){

+	filp = filp_open(config_filename, O_RDONLY, 0);

+	if (IS_ERR_VALUE(PTR_ERR(filp))){

 		// error opening the file

		ZD1211DEBUG(0, "File opening did not success\n");

 		set_fs(fs);

 		return;

 	}

+	get_file(filp);



 	/* Get information about the file. */

 	//fstat (ifp, &file_info);

@@ -8722,11 +8735,13 @@ void zd1205_load_card_setting(struct zd1
 	old_buffer = buffer;



 	/* Read the file into the buffer. */

-	bcount = read(ifp, buffer, file_length);

+	bcount = filp->f_op->read(filp, buffer, file_length, 0);

 	ZD1211DEBUG(1, "bcount=%d\n", bcount);



 	// close the file

-	close(ifp);

+	filp_close(filp, 0);



 	// switch back the segment setting

 	set_fs(fs);



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Using _syscall3 to manipulate files in a driver

[Daniel Drake]

Jon Smirl wrote:
> I have the source code for a vendor written driver that is targeted at
> 2.6.9. It includes this and then proceeds to manipulate files from the
> driver.

In future just kill the code in question, it's wrong and not needed. 
It's already mostly disabled in the code, based on my request. It is 
also not present in the community-maintained vendor driver.

Daniel