Commit Graph

34 Commits

Author SHA1 Message Date
Eivind Eklund
7b778b5e61 Make all file-system (MFS, FFS, NFS, LFS, DEVFS) related option new-style.
This introduce an xxxFS_BOOT for each of the rootable filesystems.
(Presently not required, but encouraged to allow a smooth move of option *FS
to opt_dontuse.h later.)

LFS is temporarily disabled, and will be re-enabled tomorrow.
1998-01-24 02:54:56 +00:00
Poul-Henning Kamp
ab3f746966 In all such uses of struct buf: 's/b_un.b_addr/b_data/g' 1997-12-02 21:07:20 +00:00
Poul-Henning Kamp
4a11ca4e29 Remove a bunch of variables which were unused both in GENERIC and LINT.
Found by:	-Wunused
1997-11-07 08:53:44 +00:00
Justin T. Gibbs
3544218335 Update for changes in the callout interface. 1997-09-21 21:43:54 +00:00
Bruce Evans
395d48aff0 Removed unused #includes.
Updated an #include to 4.4Lite style (missed one).
1997-07-20 11:14:53 +00:00
Joerg Wunsch
28d90c30ee Add the D_DISK flag to the cdevsw structs of various CD-ROM drivers. 1997-05-10 12:13:17 +00:00
Joerg Wunsch
5a9714de76 This mega-commit brings the following:
. 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.
1997-05-04 15:24:23 +00:00
Bruce Evans
4b04349ab9 Fixed the type of a timeout function and removed casts that hid the
type mismatches.  There was no problem in practice (at least on 386's).
The timeout args still get bogusly cast from int to `void *' via
caddr_t and back to int.
1997-04-20 18:02:40 +00:00
Bruce Evans
fce002fdef Don't include <sys/ioctl.h> in the kernel. Stage 1: don't include
it when it is not used.  In most cases, the reasons for including it
went away when the special ioctl headers became self-sufficient.
1997-03-24 11:25:10 +00:00
Bruce Evans
3ac4d1ef0c Don't #include <sys/fcntl.h> in <sys/file.h> if KERNEL is defined.
Fixed everything that depended on getting fcntl.h stuff from the wrong
place.  Most things don't depend on file.h stuff at all.
1997-03-23 03:37:54 +00:00
Peter Wemm
6875d25465 Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not
ready for it yet.
1997-02-22 09:48:43 +00:00
Jordan K. Hubbard
1130b656e5 Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
1997-01-14 07:20:47 +00:00
Satoshi Asami
e30f001135 More merge and update.
(1) deleted #if 0

    pc98/pc98/mse.c

(2) hold per-unit I/O ports in ed_softc

    pc98/pc98/if_ed.c
    pc98/pc98/if_ed98.h

(3) merge more files by segregating changes into headers.

  new file (moved from pc98/pc98):

    i386/isa/aic_98.h

  deleted:

    well, it's already in the commit message so I won't repeat the
    long list here ;)

Submitted by:	The FreeBSD(98) Development Team
1996-10-30 22:41:46 +00:00
Poul-Henning Kamp
bfbb029d87 Remove devconf, it never grew up to be of any use. 1996-09-06 23:09:20 +00:00
Poul-Henning Kamp
cba8a5ddd3 Make a "DWIM" function for adding [bc]devsw entries for bdev drivers.
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 :-)
1996-07-23 21:52:43 +00:00
Bruce Evans
7cc1644db3 Fixed existence, minor numbers, group and permissions for devfs devices
(locked devices weren't created; minor numbers didn't depend on the unit
number; group operator was games; permissions 0640 was 0600).
1996-06-08 09:17:51 +00:00
Poul-Henning Kamp
0be33caa54 Forget that TAILQ's must be init'ed. 1996-05-03 16:49:14 +00:00
Poul-Henning Kamp
540bfbd1a5 Move from the old buf.b_actf to the new TAILQ(buf.b_act).
Also remove a ton of weird comments and a couple of no-use options.
1996-05-03 14:58:11 +00:00
Marc G. Fournier
6e18ce4676 Switched from using devfs_add_sw() to using devfs_add_swf()
Reviewed by:	julian@freebsd.org
1996-03-28 14:29:52 +00:00
Peter Wemm
a5b996a7ec recording cvs-1.6 file death 1995-12-30 19:02:48 +00:00
Bruce Evans
4439655d52 Replaced nxdump by nodump (if the dump function gets called, then the
device must be configured, so ENXIO is a bogus errno).

Replaced zerosize by nopsize.  zerosize was a temporary alias.
1995-12-10 19:53:42 +00:00
Poul-Henning Kamp
6f4e0beb7e Staticize and cleanup. 1995-12-10 13:40:44 +00:00
Julian Elischer
87f6c6625d Pass 3 of the great devsw changes
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.. :)
1995-12-08 11:19:42 +00:00
Julian Elischer
7198bf4725 If you're going to mechanically replicate something in 50 files
it's best to not have a (compiles cleanly) typo in it! (sigh)
1995-11-29 14:41:20 +00:00
Julian Elischer
53ac6efbd8 OK, that's it..
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)
1995-11-29 10:49:16 +00:00
Julian Elischer
376c314995 the second set of changes in a move towards getting devices to be
totally dynamic. (the first was about 7 weeeks ago)

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 */
1995-11-28 09:43:45 +00:00
Bruce Evans
4fda91c705 Moved prototypes for devswitch functions from conf.c and driver sources
to <machine/conf.h>.  conf.h was mechanically generated by
`grep ^d_ conf.c >conf.h'.  This accounts for part of its ugliness.  The
prototypes should be moved back to the driver sources when the functions
are staticalized.
1995-11-04 13:25:33 +00:00
Jordan K. Hubbard
d6393cdba3 Bring in version 1(26) - considerably less memory usage (and may bring us
down to 4MB bootability again).
Submitted by:	Frank Durda IV <uhclem@fw.ast.com>
1995-10-25 16:41:22 +00:00
Jordan K. Hubbard
0134f4737b o Support for CDIOCPREVENT and CDIOCALLOW ioctls that xcdplayer
were making and were no-brainers.  However, the xcdplayer
    eject button didn't work because xcdplayer gave up and didn't bother
    to try the EJECT ioctl anyway when CDIOCALLOW was not available.
    This all works now.

o   A change so that xcdplayer gets TOC entry data for the lead-out area
    on the disc.  Xcdplayer can now play the last track on a CD, which
    it would not do in earlier versions (but no one reported).
    Cdplayer gets the TOC data differently and it works in old and new
    versions.

o   Eliminated a race condition that caused the driver to sleep forever
    on very slow and heavily loaded systems on rare occasions when
    the system was doing lots of audio-related ioctls to the drive.

o   Fixed a problem where a locked drive could be unlocked by accessing
    one of the non-locking devs.  Door locking now follows the documented
    rules.

o   Made all wait channel strings unique to matcd.

Submitted by: Frank Durda IV <uhclem%nemesis@fw.ast.com>
1995-09-28 13:15:49 +00:00
Bruce Evans
6003967057 Fix benign type mismatches in devsw functions. 82 out of 299 devsw
functions were wrong.
1995-09-08 11:09:15 +00:00
Jordan K. Hubbard
15c761840a Release summary: (detailed descriptions in Edit History in matcd.c)
Adds support for non-Sound Blaster host adapters, including those
distributed by Reveal, Lasermate, IBM, Media Vision, Crystal and others.
The driver automatically senses the correct adapter type and you can
have both in the system at the same time.
(This change should eliminate a few complaints.)

Corrected bit-masking problem that prevented use on SB Vibra-16 boards.

Declared some internal data and functions static that should have been
that way all along.

Documentation changes reflect the new hardware support and change the
appearance version to 2.0.5 (was 2.1).    Nice and tidy.   :-)


Beta testers have verified functionality on SB16, Vibra-16, Media Vision
and Reveal adapters.   -Wall still shows no warnings.

                                        Frank Durda IV
                                        uhclem%nemesis@fw.ast.com
Submitted by:	Frank Durda IV <uhclem%nemesis@fw.ast.com>
1995-07-11 03:03:47 +00:00
Rodney W. Grimes
d3628763db Merge RELENG_2_0_5 into HEAD 1995-06-11 19:33:05 +00:00
Rodney W. Grimes
9b2e535452 Remove trailing whitespace. 1995-05-30 08:16:23 +00:00
Jordan K. Hubbard
08d5844ce1 This is the new submission of the matcd driver. In addition to the
new driver code, there are diffs to several other existing files
on the system and a man page.

This version of matcd implements the rest of the key ioctls related to
playing audio CDs and reading table of contents information from any
type of disc.

This update also corrects several problems detected since the original
version 1(10) was released.  These include:
1.	Jordons report on the kernel -c string problem.
2.	A problem with the driver being confused by other types of
	devices located at addresses it probes.
3.	An old CD TOC wouldn't always be cleared after a disc change.
4.	Cleaned up code so -Wall yields no warnings on 2.0 and later.
5.	A problem with drive getting out of sync with the driver when
	changing between CD-Data and CD-DA.

There have only been two reports from the field relating to problems
so either the first release isn't really being used or doesn't have
many problems.

If there are any problems with this submission, please let me know.

Submitted by:	Frank Durda IV <uhclem%nemesis@fw.ast.com>
1995-04-09 15:50:27 +00:00