see below...
PS (Pre-script) does anyone know how to get MS outlook to append your reply
to the END of the quoted message, rather than put it at the beginning?
Simon Wood
Hardware Engineer
Pace Micro Technology plc
Victoria Road, Saltaire, Shipley
West Yorkshire, BD18 3LF
Tel : +44(0)1274 532000 Fax: +44(0)1274 532029
This E-Mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender.
> -----Original Message-----
> From: Alistair Riddoch [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, June 28, 1999 3:06 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Can someone explain (or point me towards an explaination
> for) the
>
> IMPORTANT NOTE: Do not use any code in 0.0.77 as a reference for writing
> this driver. Please see 0.0.76 instead. I accidentally released some
> experimental code which will not be in the next release, and does not make
> sense. The code is not buggy, just unnecessary and wrong. If you write a
> driver like this it won't work with future kernels. END
[<Simon Wood>]
Whoops.
> The ramdisk driver is probably the best driver to use as a template. It is
> very simple, does not use interrupts or waiting, and copies memory in the
> simplest way. The block_read and block_write functions are generic
> function
> which allow character orientated reads/writes to occur on a block device.
> These are only used by things like mkfs and fsck.
>
> The important function for your driver to implement are the open and
> release functions, and the request function. You then create a
> file_operations structure just like the one in rd.c, but with entries
> pointing
> to your open, and release function (you won't need an ioctl yet). The open
> and release functions may or may not need to do anything, but they should
> verify that the device being accessed is valid, and return an error if
> not.
> Most of the functionality will be in the request function (see
> do_rd_request()) which actually reads and writes blocks.
>
[<Simon Wood>]
Had a look-see at this and got confused, looked again and did LOTS of fgreps
and think I understand a little more.
Could this area of code be 'cleaned up' to make it a little more readable?
(do_rd_request() seems to be called via a #define).
questions:
What is ioctl() for ?
Am I correct in assuming that this is running as kernel (i.e. kernel data
segment)?
Why is 512 hardcoded?
If accesses are going to take a largish period of time is this going to get
swapped out, or does the kernel reign supreme?
> You will then need an init function for the driver which calls
> register_blkdev
> and stores a pointer to the request function in the blk_dev array of
> structures in the correct place.
>
> Then all you have to do is put a call to this function in blk_dev_init()
> in
> ll_rw_blk.c, and you have your driver.
>
> Al
