Linux Driver**HELP**

[twisted1]

I am currently working on a project for a motion control board from national semiconductor. It connects to an ISA board built by the company I work for. I am using Red Hat 2.4.2-2 and need help on how to test Read/Write on this board. Anyone know how to write drivers? I have a bit done I'm just stuck as this is my first.....Please help me.

[gfreehed]

Try this book from O'Reilly (or find a copy on the internet!)

http://safari.oreilly.com/?XmlId=0-59600-008-1

[twisted1]

Thanks for the reply. I already have that book. It helped a little but I'm still having some problems. I was wondering if there was some sites, or if anyone has personally written an ISA driver that could give some input. Do you know of any other books as good as the O'Reily? Thanks again.

[Stuka]

So what is it that you need to do? Test the read/write calls? If so, you can use cat and/or grep to test those functions. cat "blah" > /dev/my_device will test your open() and write() calls. Similar shell commands can be used to test read() functionality.

[twisted1]

The "blah" is just garbage to put in to get a response from the card I presume? Will trhis give me the same garbage back if I am actually talking to the card? I really appreciate your time and input. This is what makes the Linux community so much better then ...whats that other OS?:) Thanks again.

[binaryDigit]

cat "blah" > /dev/my_device

sends the string "blah" to your device

to get something back you have to do one of the following:

cat /dev/my_device
tail -f /dev/my_device
less -f /dev/my_device

[twisted1]

Oh, so it will hold "blah" in memory, right?.. Sorry if I ask too many questions I just like to make sure I understand. Thanks you guys soooo much for being cool..Anyway what I have done is hook up an LED to a cable atached to the card and I have the motion controller atached to the parralell port on the back of the card. So if the card is written to the LEDs, in theory, should light up.

[binaryDigit]

blah would be the data sent to the device
so doing:
cat "blah" > /dev/some_device

would send the string "blah" to the device by writing it to the device file -> /dev/some_device, not to memory (and when i say memory i mean ram, considering the hard drive is memory too)


i hope that clears it up for you.

[bwkaz]

When your driver registers itself with the kernel (you do have an official device number, correct? You're not taking someone else's? Check the devices.txt in the kernel source Documentation directory), you provide the kernel with routines that it calls when a user program writes to your device, reads from your device, calls ioctl() on your device, and a couple of other operations (open, probably, and if open, then close).

The data does get stored in memory -- your routine gets a pointer to it (and probably a length value as well). Your driver is responsible for starting bus transactions to actually perform the write on the hardware end -- that I don't have a clue how to accomplish.

[binaryDigit]

IIRC ioctl() is being eliminated with kernel 2.6
i believe they're doing away with the devfs completely.
i'm not sure about the specifics.

[bwkaz]

Umm?

A quick grep of the 2.5.68 source for ioctl returns 1610 unique files still having some reference to the word (this doesn't mean they all implement an ioctl themselves, as it could exist in a comment, but I'd say most of them do). The command I ran was grep -r ioctl * | cut -d: -f1 | sort | uniq | wc -l, if you want to check for yourself. Getting rid of ioctl() would be a massively complicated job, which would also make the Linux kernel be non-POSIX compliant, I believe. Seeing as every Unix that I know of supports ioctl(), anyway...

And the fs/devfs/ directory most definitely still exists. I can't see why Richard Gooch would put all that time into getting it into the tree, just to have it chopped back out later. Possible, yes, but I don't see why it'd happen.

And even without devfs, the data that gets passed to the function that you register with the kernel for a write call still only exists in memory. Nothing is ever written to disk unless you do it yourself, in the driver.

[binaryDigit]

Originally posted by bwkaz
Umm?

A quick grep of the 2.5.68 source for ioctl returns 1610 unique files still having some reference to the word (this doesn't mean they all implement an ioctl themselves, as it could exist in a comment, but I'd say most of them do). The command I ran was grep -r ioctl * | cut -d: -f1 | sort | uniq | wc -l, if you want to check for yourself. Getting rid of ioctl() would be a massively complicated job, which would also make the Linux kernel be non-POSIX compliant, I believe. Seeing as every Unix that I know of supports ioctl(), anyway...

And the fs/devfs/ directory most definitely still exists. I can't see why Richard Gooch would put all that time into getting it into the tree, just to have it chopped back out later. Possible, yes, but I don't see why it'd happen.

And even without devfs, the data that gets passed to the function that you register with the kernel for a write call still only exists in memory. Nothing is ever written to disk unless you do it yourself, in the driver.

i must have been mistaken about the ioctl() stuff then.

i have a question for you then. if i do:
cat "something" > /dev/some_dev
then that's a write to the device file.
the driver for the device picks that up correct?

[Stuka]

Yup...the kernel calls the "open" and "write" functions of the driver when you do that.

[twisted1]

I will have to try these out this week coming as, to my complete and utmost astonishment, the computer at work lost it's boggle and will no longer come up in x window. I tied to do startx but it keeps giving me error messages.:confused: But anyway I will reload the OS and hopefully get your suggestions to work . I again appretiate all the help you guys. Thanks!!
Mike (Twisted1):)

[error27]

binaryDigit: there are tons of ioctl in linux. some old ones were removed from a driver a couple weeks ago. I think that may be what you're thinking of.

[binaryDigit]

Originally posted by error27
binaryDigit: there are tons of ioctl in linux. some old ones were removed from a driver a couple weeks ago. I think that may be what you're thinking of.
i think you might be right about that. it was probably just in one part, and i misread.