Very rudimentary, lots of error checks missing, but it works.
Dont do an ls on two different CD's though, it will eat your
changer mechanism for lunch :), this clearly needs some more
thought. Until then this will enable those with changers to
mount their multible CD's and doing "sensible" work....
Thanks to Andrew Gordon <arg@arg1.demon.co.uk> for donating a drive
(a NEC CDR-C251 4x4) that makes this possible to develop.
buffer queue so I missed this when I changed buf_queue_head.
This probably fixes Soren's problem too, but he never mentioned
which CD driver he was using. 8-)
Submitted by: dave adkins <adkin003@tc.umn.edu>
. It makes cd9660 root f/s working again.
. It makes CD9660 a new-style option.
. It adds support to mount an ISO9660 multi-session CD-ROM as the root
filesystem (the last session actually, but that's what is expected
behaviour).
Sigh. The CDIOREADTOCENTRYS did a copyout() of its own, and thus has
been unusable for me for this work. Too bad it didn't simply stuff
the max 100 entries into the struct ioc_read_toc_entry, but relied on
a user supplied data buffer instead. :-( I now had to reinvent the
wheel, and created a CDIOREADTOCENTRY ioctl command that can be used
in a kernel context.
While doing this, i noticed the following bogosities in existing CD-ROM
drivers:
wcd: This driver is likely to be totally bogus when someone tries
two succeeding CDIOREADTOCENTRYS (or now CDIOREADTOCENTRY)
commands with requesting MSF format, since it apparently
operates on an internal table.
scd: This driver apparently returns just a single TOC entry only for
the CDIOREADTOCENTRYS command.
I have only been able to test the CDIOREADTOCENTRY command with the
cd(4) driver. I hereby request the respective maintainers of the
other CD-ROM drivers to verify my code for their driver. When it
comes to merging this CD-ROM multisession stuff into RELENG_2_2 i will
only consider drivers where i've got a confirmation that it actually
works.
Use the name argument almost the same in all LKM types. Maintain
the current behavior for the external (e.g., modstat) name for DEV,
EXEC, and MISC types being #name ## "_mod" and SYCALL and VFS only
#name. This is a candidate for change and I vote just the name without
the "_mod".
Change the DISPATCH macro to MOD_DISPATCH for consistency with the
other macros.
Add an LKM_ANON #define to eliminate the magic -1 and associated
signed/unsigned warnings.
Add MOD_PRIVATE to support wcd.c's poking around in the lkm structure.
Change source in tree to use the new interface.
Reviewed by: Bruce Evans
Saves about 280 butes of source per driver, 56 bytes in object size
and another 56 bytes moves from data to bss.
No functional change intended nor expected.
GENERIC should be about one k smaller now :-)
most devsw referenced functions are now static, as they are
in the same file as their devsw structure. I've also added DEVFS
support for nearly every device in the system, however
many of the devices have 'incorrect' names under DEVFS
because I couldn't quickly work out the correct naming conventions.
(but devfs won't be coming on line for a month or so anyhow so that doesn't
matter)
If you "OWN" a device which would normally have an entry in /dev
then search for the devfs_add_devsw() entries and munge to make them right..
check out similar devices to see what I might have done in them in you
can't see what's going on..
for a laugh compare conf.c conf.h defore and after... :)
I have not doen DEVFS entries for any DISKSLICE devices yet as that will be
a much more complicated job.. (pass 5 :)
pass 4 will be to make the devsw tables of type (cdevsw * )
rather than (cdevsw)
seems to work here..
complaints to the usual places.. :)
That's EVERY SINGLE driver that has an entry in conf.c..
my next trick will be to define cdevsw[] and bdevsw[]
as empty arrays and remove all those DAMNED defines as well..
Each of these drivers has a SYSINIT linker set entry
that comes in very early.. and asks teh driver to add it's own
entry to the two devsw[] tables.
some slight reworking of the commits from yesterday (added the SYSINIT
stuff and some usually wrong but token DEVFS entries to all these
devices.
BTW does anyone know where the 'ata' entries in conf.c actually reside?
seems we don't actually have a 'ataopen() etc...
If you want to add a new device in conf.c
please make sure I know
so I can keep it up to date too..
as before, this is all dependent on #if defined(JREMOD)
(and #ifdef DEVFS in parts)
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
Convert the remaining sysctl stuff to the new way of doing things.
the devconf stuff is the reason for the large number of files.
Cleaned up some compiler warnings while I were there.
from a string to an identifier so that it can be used to generate
declarations and strings. It's much easier to stringize an identifier
than to identifize a string. A uniform naming scheme must be used
for the automatically generated things to apply. This is a feature.
Used the module identifer to generate prototypes for the module load,
unload and stat functions. Removed the few prototypes for these that
already existed.
Used the module identifier to generate a unique struct tag in MOD_DEV().
This should probably be done for all the MOD_*() macros.
Moved the trailing semicolon from the MOD_*() macro definitions to the
macro invocations that didn't already (bogusly) have it.
Staticized the module load and unload functions.
Added function return types for the module load, unload and stat functions.
lkm/ibcs2/ibcs2.c:
Included <sys/sysproto.h> to get everything prototyped.
Cleaned up #includes.
lkm/ibcs2/ipfw.c:
Cleaned up #includes.
lkm/linux/linux.c:
The module name had to change from "linux_emulator" to "linux_mod" to
be automatically generated.
Cleaned up #includes.
lkm/syscons/*/*_saver.c:
Completed delcarations of function pointers.
sys/i386/isa/atapi.c:
The module name had to change from "atapi" to "atapi_mod" to be
automatically generated.
sys/i386/isa/wcd.c:
Used the fixed MOD_DEV(). This module has two devices and expanded the
macro in the source instead of fixing it.
The module names had to change from "wcd" and "rwcd" to "wcd_mod" and
"rwcd_mod" to be automatically generated.
sys/pccard/pcic.c:
The module name had to change from "pcic" to "pcic_mod" to be
automatically generated.
I tried to solve the problem of IDE probing compatibility in this version.
When compiled without an ATAPI option, the wd driver is
fully backward compatible with 2.0.5. With ATAPI option,
the wdprobe becomes strictly weaker. That is, if wdprobe works
without ATAPI option, it will always work with it too.
Another problem was with the CD-ROM drive attached as a slave
in the IDE bus, where there is no master. All IDE CD-ROM
drives are shipped in slave configuration, and most users
just plug them in, never thinking about jumpers.
It works fine with ms-dos and ms-windows, and this
version of the driver supports it as well.
The eject op can now load disks. Just repeat it twice,
and the disk will be ejected and then loaded back.
The disc cannot be ejected if it is mounted.
Submitted by: Serge Vakulenko, <vak@cronyx.ru>
by me...
Original message:
This patch upgrades the ATAPI CD-ROM driver to version 1.3.
It has three bugs fixed:
1) The `controller not ready' message at startup and later.
It was caused by staled media change bit.
2) Incorrect shuffling of model string for some drives (NEC, Mitsumi).
3) Handling of drives which report itself as been of direct-access type,
instead of CD-ROM type.
There is one known bug which is not fixed yet -- probing
in absense of IDE disks. A work-around exists though (thanks Steve!).
If you have no IDE disks attached, then remove them from the kernel
config file to make the CD-ROM attach correctly.
Unfortunately, there is no way to disable them from the kernel
interactive config mode.
Reviewed by: sos (Soren Schmidt)
Submitted by: vak@gw.cronyx.msk.su (Serge V.Vakulenko)
