On Wednesday 04 June 2003 1:26 pm, Paul Richards wrote:
On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
Notice how thread 1's _m gets set based on the results of the
kobj
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface
On Thu, 2003-06-05 at 15:51, Paul Richards wrote:
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects
On Thu, Jun 05, 2003 at 04:06:16PM +0100, Doug Rabson wrote:
On Thu, 2003-06-05 at 15:51, Paul Richards wrote:
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Paul Richards wrote:
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote:
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
How can you add an interface at runtime?
By loading a kernel module. If I load e.g. the agp kernel module, I add
the agp_if interface to the kernel.
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface was added) will continue
to work as before. If methods from the new interface are called on old
objects, the default
On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface was added) will continue
to work as before. If methods from the
On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote:
On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote:
Hiten Pandya wrote:
My fingers have been itching to do this since the day phk@ planted this
idea in my brain (re: cdevsw initialisations). Basically, it changes
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: You should look at kobj, it's precisely this sort of dynamic
: dispatching that it was designed to support.
Too bad it is a little slow and not MP safe in its implementation.
Warner
On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: You should look at kobj, it's precisely this sort of dynamic
: dispatching that it was designed to support.
Too bad it is a little slow and not
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say the device driver code will not interact with
: it's use by
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say the
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be exceptionally rare and with our present usage we'd never
have that happen.
I'm not sure
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: Doug, am I missing something?
I think we can have more than 256 methods, en toto, since any object
can implement multiple interface types and we don't know, a-priori,
how many different interfaces a given object
On 02-Jun-2003 Paul Richards wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be exceptionally rare and with our present usage we'd
In message [EMAIL PROTECTED], John Baldwin writes:
On 02-Jun-2003 Paul Richards wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], John Baldwin writes:
On 02-Jun-2003 Paul Richards wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
The tradeoff with using an index into an array is that there'd be a
heavy penalty for
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available in an interface are fixed, they're
: defined in the .m files.
No it isn't. One can add additional interfaces at any time without
breaking binary compatibility, so you don't know, a
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available in an interface are fixed, they're
: defined in the .m files.
No it isn't. One can add additional interfaces at any time
In message [EMAIL PROTECTED], Paul Richards wr
ites:
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
I thought the point in KOBJ was that it was extensible so you could
KLD load stuff which added more methods ?
Not exactly. It allows for dynamic binding of methods that implement a
On Wed, 2003-06-04 at 00:03, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Paul Richards wr
ites:
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
I thought the point in KOBJ was that it was extensible so you could
KLD load stuff which added more methods ?
Not exactly. It
Paul Richards wrote:
On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote:
And how many times is vfc_register() called? Its not in the
patch of an I/O operation or anything. Its just a mount time
overhead which will go through -- a one time thing.
On Mon, Jun
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available in an interface are fixed, they're
: defined in the .m files.
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2 took out their
driver instance locks.
That means we have to
On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote:
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: The possible methods available
On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote:
On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2
On Wed, 2003-06-04 at 13:24, Paul Richards wrote:
On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote:
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL
Hiten Pandya wrote:
My fingers have been itching to do this since the day phk@ planted this
idea in my brain (re: cdevsw initialisations). Basically, it changes
the vfsops to use C99 sparse format, just like cdevsw. It removes a lot
of junk default initialisations, and duplication.
I really
On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote:
Hiten Pandya wrote:
My fingers have been itching to do this since the day phk@ planted this
idea in my brain (re: cdevsw initialisations). Basically, it changes
the vfsops to use C99 sparse format, just like cdevsw. It removes
Hiten Pandya wrote:
Consider this going forward: someone adds a new VFSOP to the
list of allowable VFSOPs, and the vfs_init() doesn't have any
specific code for it.
Considered. Now consider this, would you argue this about the
sparse cdevsw initialisation in make_dev()?
On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote:
This is a different thing entirely... you are not adding
elements in the cdevsw case.
Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse
init?
The VFSOP case is less of a problem than the VOP case, but
Hiten Pandya wrote:
On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote:
This is a different thing entirely... you are not adding
elements in the cdevsw case.
Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse
init?
Yes. You are not adding new
Gang,
My fingers have been itching to do this since the day phk@ planted this
idea in my brain (re: cdevsw initialisations). Basically, it changes
the vfsops to use C99 sparse format, just like cdevsw. It removes a lot
of junk default initialisations, and duplication.
Just like phk@ said in
33 matches
Mail list logo
