cdevsw_add() removal patch.
Please run this patch on you current machine and report any problems you might notice! Background: All dev_t's in the system should be created with an explicit make_dev() call and the old wildcard cdevsw[] mechanism be killed to the extent we can. This patch covers what I think is the trivial drivers, and if no problems are reported I will sweep all these drivers for cdevsw_add() related code and commit it one by one. If you know any of the drivers involved and know for sure that the driver is covered with make_dev() calls (ie: it works correctly on DEVFS systems) please feel (more than) free to remove the cdevsw_add() call yourself. Poul-Henning http://phk.freebsd.dk/patch/cdevsw_add.patch Remove the majority of the cdevsw_add() calls in the kernel. All main-stream drivers have been fixed for DEVFS which by definition makes cdevsw_add() calls unneeded for both the DEVFS and !DEVFS cases. I have not removed the cdevsw_add() calls from driver where I think it might make a difference for the !DEVFS case still or where I could not figure out what was going on. This patch is not the commit-ready version, but offered as a HEADSUP for people to test the effect of the actual patch on their systems. The actual patch will remove the entire cdevsw_add() family. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
While on the topic: Who is working on devfs and why not? I'd like to know whether there is some interest in getting that work underway again. More than interested to help. You're forgetting that devsw[] is another stopgap. The kernel should probably use something like devfs, where dev_t's only exist for devices that actually exist. xxx_init() is far too early to decide which hardware devices exist. Bruce Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
In message pine.gso.3.95q.990605103111.15420k-100...@elect8, Nick Hibma writes: While on the topic: Who is working on devfs and why not? I'd like to know whether there is some interest in getting that work underway again. More than interested to help. I'm not currently working on devfs, but I am building the infrastructure it should be based on in the kernel. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
While on the topic: Who is working on devfs and why not? I'm not currently working on devfs, but I am building the infrastructure it should be based on in the kernel. Anymore information available on where you are with this? Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
In message pine.gso.3.95q.990605113837.15420q-100...@elect8, Nick Hibma
writes:
While on the topic: Who is working on devfs and why not?
I'm not currently working on devfs, but I am building the infrastructure
it should be based on in the kernel.
Anymore information available on where you are with this?
I currently have a kernel running where dev_t is a pointer to a
struct dev and where char and block devs are collapsed at the
dev_t level. There are some bogons i need to fumigate, but I'm
off to give a course in Stockholm much of this coming week, so
don't expect any commits just now. (I may actually postpone/abandon
this step for now, since some of the changes pulls rugs away which
cover what looks to me like holes in the floor).
Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
code.
When I have that bit down and done, the next step is for device
drivers to register individual dev_t's rather than blanket cdevsw
entries. The later ability will be retained for pseudo drivers
and other (pseudo)magic.
This registration will look pretty much like the current #ifdef'ed
DEVFS stuff, and in addition it will allow the driver to hang two
fields of the dev_t, typically a pointer to the struct softc and
maybe a unit number or something. This will obsolete all of
the magic minor - {unit|softc} converters in our drivers and
make the NFOO configuration obsolete.
That is, as such the end of this little project, and where a future
DEVFS could take off from. Basically all that is needed for a DEVFS
to do, is to hook into the dev_t maintenance code and construct
the directory tree.
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
In message pine.gso.3.95q.990605113837.15420q-100...@elect8, Nick Hibma
writes:
While on the topic: Who is working on devfs and why not?
I'm not currently working on devfs, but I am building the infrastructure
it should be based on in the kernel.
Anymore information available on where you are with this?
I currently have a kernel running where dev_t is a pointer to a
struct dev and where char and block devs are collapsed at the
dev_t level. There are some bogons i need to fumigate, but I'm
off to give a course in Stockholm much of this coming week, so
don't expect any commits just now. (I may actually postpone/abandon
this step for now, since some of the changes pulls rugs away which
cover what looks to me like holes in the floor).
Next is to integrate the dev_t anti-aliasing and vnode anti-aliasing
code.
When I have that bit down and done, the next step is for device
drivers to register individual dev_t's rather than blanket cdevsw
entries. The later ability will be retained for pseudo drivers
and other (pseudo)magic.
This registration will look pretty much like the current #ifdef'ed
DEVFS stuff, and in addition it will allow the driver to hang two
fields of the dev_t, typically a pointer to the struct softc and
maybe a unit number or something. This will obsolete all of
the magic minor - {unit|softc} converters in our drivers and
make the NFOO configuration obsolete.
That is, as such the end of this little project, and where a future
DEVFS could take off from. Basically all that is needed for a DEVFS
to do, is to hook into the dev_t maintenance code and construct
the directory tree.
DEVFS has always meant to do exactly this.
there is already a place in the structure for these two fields,
and when devfs is running, the devsw[] table is not consulted.
The vnode already contains a direct pointer to the devsw entry and a
cookie (minor number), and these are called directly.
there is already a node type for the 'unified' device type.
there are three types of device in devfs
BDEV, CDEV and DDEV.
DDEV has only a pointer to teh methods and a cookie. (as you suggest
above)
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
Basically I'm not working on devfs at the moment since the bit that made it workable was ripped out with extreme prejudice by someone. I'm still absolutly convinced that a dynamic device registration and export framework is required in the long run, but I'm not fussed if it's based on the current devfs or an successor. I'd feel a bit happier about spending more time on it If I had any thought that the result would not be ripped out by the throat as soon as it works again, by a maniac that doesn't understand that it's a working subsystem (it was fully working at the time it was vandaliased but the nice fellow didn't even try it, and I got no warning except the commit message). There were two known problems that were based in other parts of the code (mfs and some vfs/module stuff) And the install software couldn't install with it. If PHK is working an a framework to make this easier, I'd love to get a white-paper on the topic because it's all unknown stuff at the moment. To get it going, you basically need to reverse the backout commits done by SOS a year ago. DEVSF itself works, but it needs a different disk subsystem to be able to represent dynamic disk partitions properly. julian On Sat, 5 Jun 1999, Nick Hibma wrote: While on the topic: Who is working on devfs and why not? I'm not currently working on devfs, but I am building the infrastructure it should be based on in the kernel. Anymore information available on where you are with this? Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
In message 3757c851.4...@cs.strath.ac.uk, Roger Hardiman writes:
Hi there,
Just a quick question.
I'm about to fix the cdevsw_add(bktr_cdevsw);
bug in the brooktree848.c driver.
Bruce wondered if this should go into bktr_attatch rather
than bktr_probe?
What do you think?
I think _attach is better. Otherwise we will call cdevsw_add()
even if you have the bktr driver in the kernel and have no bt848
card fitted
Today I don't much care where you put it. In the future we may
want to think more about it though.
The way I see it is that if the driver is there, it should check
in at cdevsw[], which is why I generally put in *probe().
Of course if the hardware comes 'round later, attach will get
called too.
The next moves on my part are roughly:
1. Remove the difference between cdev/bdev dev_t's. I have a
kernel running with this now, but there are bogons lurking which
I have fumigated yes.
2. Enable doing per dev_t registration in the drivers. This will
look pretty much like the devfs registration in there today, only
more sane. After this the cdevsw_add() will only be kind of a
wildcard registration method, for pseudo devices and such.
After this point, a typical driver will probably do something like this:
struct softc {
int this;
char that;
bla
bla
bla
};
/* some kind of probe/attach routine */
somefunction()
{
struct softc *sc;
dev_t dt;
dum
di
dah
/* Aha, hardware! */
sc = MALLOC(...);
bzero(sc, sizeof *sc);
dt = mkdev(
CDEV_MAJOR, /* Char major */
BDEV_MAJOR, /* Block major */
foomble_devices * 16, /* Minor */
foomble_cdevsw,/* The cdevsw function vector */
foomble%d, foomble_devices); /* printf like construction of
name */
dt-driver1 = sc;
dt-driver2 = foomble_devices;
foomble_devices++;
}
foomble_open(dev_t dev, ...)
{
struct softc *sc = dev-driver1;
int unit = dev-driver2;
}
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
This should definitely go into attach IMNSHO.
Probe: Check whether hardware is there (no side effects if possible).
Attach:Get the device up and running and integrated into the kernel.
With the priority probes this is even more distinct as a priority not
equal to 0 means 'no side effects, just checking'.
Nick.
On Fri, 4 Jun 1999, Poul-Henning Kamp wrote:
In message 3757c851.4...@cs.strath.ac.uk, Roger Hardiman writes:
Hi there,
Just a quick question.
I'm about to fix the cdevsw_add(bktr_cdevsw);
bug in the brooktree848.c driver.
Bruce wondered if this should go into bktr_attatch rather
than bktr_probe?
What do you think?
I think _attach is better. Otherwise we will call cdevsw_add()
even if you have the bktr driver in the kernel and have no bt848
card fitted
Today I don't much care where you put it. In the future we may
want to think more about it though.
The way I see it is that if the driver is there, it should check
in at cdevsw[], which is why I generally put in *probe().
Of course if the hardware comes 'round later, attach will get
called too.
The next moves on my part are roughly:
1. Remove the difference between cdev/bdev dev_t's. I have a
kernel running with this now, but there are bogons lurking which
I have fumigated yes.
2. Enable doing per dev_t registration in the drivers. This will
look pretty much like the devfs registration in there today, only
more sane. After this the cdevsw_add() will only be kind of a
wildcard registration method, for pseudo devices and such.
After this point, a typical driver will probably do something like this:
struct softc {
int this;
char that;
bla
bla
bla
};
/* some kind of probe/attach routine */
somefunction()
{
struct softc *sc;
dev_t dt;
dum
di
dah
/* Aha, hardware! */
sc = MALLOC(...);
bzero(sc, sizeof *sc);
dt = mkdev(
CDEV_MAJOR, /* Char major */
BDEV_MAJOR, /* Block major */
foomble_devices * 16, /* Minor */
foomble_cdevsw,/* The cdevsw function vector */
foomble%d, foomble_devices); /* printf like construction of
name */
dt-driver1 = sc;
dt-driver2 = foomble_devices;
foomble_devices++;
}
foomble_open(dev_t dev, ...)
{
struct softc *sc = dev-driver1;
int unit = dev-driver2;
}
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
Nick Hibma wrote: cdevsw_add() This should definitely go into attach IMNSHO. Probe: Check whether hardware is there (no side effects if possible). Attach:Get the device up and running and integrated into the kernel. With the priority probes this is even more distinct as a priority not equal to 0 means 'no side effects, just checking'. I've just fixed the bt848 driver (bktr) where the cdevsw_add() was accidentally added to the BSDI bktr_probe() and not the FreeBSD bktr_probe. Although Bruce and Nick said this really belongs, in the _attatch() function, I've kept it in the _probe() function for consistency with all the other drivers. Roger -- Roger Hardiman| Telepresence Research Group ro...@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
I've just fixed the bt848 driver (bktr) where the cdevsw_add() was accidentally added to the BSDI bktr_probe() and not the FreeBSD bktr_probe. Although Bruce and Nick said this really belongs, in the _attatch() function, I've kept it in the _probe() function for consistency with all the other drivers. Hm, I think this a bad choice. Which are 'all the other drivers'? The probe should really be as thin as possible to avoid unnecessary delays when probing in a kernel, like GENERIC, with a lot of device drivers compiled in. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
Nick Hm, I think this a bad choice. Which are 'all the other drivers'? The probe should really be as thin as possible to avoid unnecessary delays when probing in a kernel, like GENERIC, with a lot of device drivers compiled in. Well, in the PCI drivers, it is just the meteor, the brooktree848 and the Xilinx PGA driver (xrpu) In the /sys/i386/isa drivers, there were quite a few. Bye Roger -- Roger Hardiman| Telepresence Research Group ro...@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
Hm, I think this a bad choice. Which are 'all the other drivers'? The probe should really be as thin as possible to avoid unnecessary delays when probing in a kernel, like GENERIC, with a lot of device drivers compiled in. Well, in the PCI drivers, it is just the meteor, the brooktree848 and the Xilinx PGA driver (xrpu) In the /sys/i386/isa drivers, there were quite a few. The isa drivers provide many bad examples. Most of them attached the devsw in a disgusting SYSINIT even if the device is disabled. I moved the devsw attach to the device attach function in some drivers that I worked on. This was necessary to support pcvt and syscons sharing a devsw entry. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Bruce Evans wrote: The isa drivers provide many bad examples. Most of them attached the devsw in a disgusting SYSINIT even if the device is disabled. I moved the devsw attach to the device attach function in some drivers that I worked on. This was necessary to support pcvt and syscons sharing a devsw entry. Firstly, the SYSINIT code was a stopgap. It will evolve with time.. The question is one of scope. THe devsw[] entry is added at the same time that the driver is activated in the kernel. This is neither at the first probe of a particular device, nor at the attach. Both of the latter cases an occur many times, both before (for probe) and after teh first hardware is found. This is why the SYSINIT was used.. The idea was that a loadable module would have an init() routine that is called when the module is loaded and linked in. This init() should also be called in an identical way during boot for a pre-loaded module. basically the case of a preloaded module (driver) is just a special case of the more general case of a loadable module. Drivers are just a special case of the more general case of loadable modules, so a driver should have all the features of a general module. e.g. an init() routine of some sort. It therefore makes sense that if a driver module has an init() routine that is called once before any other calls to the driver, tehn this is the obvious place to do things such as installing hooks for shutdown, or timeouts etc. and for installing itself into structures such as the devsw[] arrays. It is possible to SIMULATE this by making the first probe or attach calls do the work, but it seems to me rather artificial to do so because we have the ideal place to do the work anyhow. Remember that one of the long term aims that nearly all the FreeBSD developers have expressed at one time or another is to make FreeBSD almost completely dynamic. This means that nearly all components will eventually be loadable. Including boot drivers, which can be loaded and linked in by the boot loader. Making all drivers have the 'form' required, with an separate init() routine to be called at load time is therefore a positive thing. SYSINIT is just a way of making sure that these are called early, so that the driver need not know if it was loaded or was 'preloaded'. I therefore put it to the group that the right place to do devsw[] manipulation is neither in xxx-probe, or _attach, but in xxx_init(), which is only called once, and IS called at teh right time. It should also be noted that teh devsw[] extraction code should be run from the init() code when it is run with the 'shutdown' argument. (but only when the driver arees to allow itself to be unlinked). julian Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
On Sat, 5 Jun 1999, Bruce Evans wrote: Hm, I think this a bad choice. Which are 'all the other drivers'? The probe should really be as thin as possible to avoid unnecessary delays when probing in a kernel, like GENERIC, with a lot of device drivers compiled in. Well, in the PCI drivers, it is just the meteor, the brooktree848 and the Xilinx PGA driver (xrpu) In the /sys/i386/isa drivers, there were quite a few. The isa drivers provide many bad examples. Most of them attached the devsw in a disgusting SYSINIT even if the device is disabled. I moved the devsw attach to the device attach function in some drivers that I worked on. This was necessary to support pcvt and syscons sharing a devsw entry. If people feel that its wrong to put the cdev registration in a sysinit, please feel free to rip out the DEV_DRIVER_MODULE stuff and replace it with whatever the 'right thing' is. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
The isa drivers provide many bad examples. Most of them attached the devsw in a disgusting SYSINIT even if the device is disabled. I moved the devsw attach to the device attach function in some drivers that I worked on. This was necessary to support pcvt and syscons sharing a devsw entry. Firstly, the SYSINIT code was a stopgap. It will evolve with time.. The Like most stogaps, it was there too long (3.5 years). It is mostly gone now. ... I therefore put it to the group that the right place to do devsw[] manipulation is neither in xxx-probe, or _attach, but in xxx_init(), which is only called once, and IS called at teh right time. It should also be noted that teh devsw[] extraction code should be run from the init() code when it is run with the 'shutdown' argument. (but only when the driver arees to allow itself to be unlinked). You're forgetting that devsw[] is another stopgap. The kernel should probably use something like devfs, where dev_t's only exist for devices that actually exist. xxx_init() is far too early to decide which hardware devices exist. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cdevsw_add
In message 199906042048.gaa25...@godzilla.zeta.org.au, Bruce Evans writes: You're forgetting that devsw[] is another stopgap. The kernel should probably use something like devfs, where dev_t's only exist for devices that actually exist. xxx_init() is far too early to decide which hardware devices exist. Patience Bruce, I'm getting closer to that all the time... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
