On Wed, 12 Sep 2001, Monty Vanderbilt wrote:
|>Let me know if I'm off base here, but I'm having trouble getting lkcd_config
|>to work. I'm just learning about linux device drivers so I apologize in
|>advance for dumb questions.
|>
|>1) The symptom is that the open works, but all ioctl calls (query and set)
|>return I/O error. My suspicion is that with a dump driver in the system the
|>/dev/dump device can no longer be a symbolic link to the swap device. But
|>the \lkcdutils\README files still describe the setup like this.
|>
|>2) 3 of the 4 ioctls in the query portion of lkcd_config are passing the
|>"set" code rather than the "get" code.
Fixed. Check out the new version. Thanks.
|>3) I'm confused about the file access:
|>
|> dfd = open(DUMP_DEVICE, O_RDONLY) // opens hard-coded device name
|>/dev/dump
|>
|> fd = open(device_name, O_RDONLY) // opens the device name
specified on
|>the command line
|>
|> - dfd is used for the device operations, but fd is not, except to get a
|>dnum. Why is the device name hard-coded?
/dev/dump is now the representative "dump device driver". There will
be the extension in the future of having multiple dump methods beyond
/dev/dump. What this means is, you tell /dev/dump what device number
or device name to dump to. For example, /dev/dump will use /dev/hda4 as
its representative dump device if that's what you specify.
In fact ...
I'm going to move this to /dev/dump/dumpN tonight. So assume that
the code is going to change one more time. This also means /sbin/lkcd
also changes.
|> - the define is opened read-only but "set" ioctls are performed. Is this
|>OK?
This is now fixed, but I also need to fix the open/ioctl. Good point.
|>4) When I get the latest set of sources I'm still getting the old "vmdump"
|>files. Is there a way around this?
I left them in there until we reach a point where we're ready to
remove them and move entirely to the new method. First, the old
files will be moved into a 2.4-old, and the new files will be in
the 2.4 directory.
Nice to see some people using the CVS tree. :)
Let me know if you find anything else.
--Matt
|>Monty VanderBilt
|>Amazon.com
|>
|