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
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 ke
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 wro
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. Exist
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
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 fr
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 defaul
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]>
> > > >
> > > > Pa
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 a
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 m
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
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
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.
> >
> > O
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 ?
> >
>
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
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
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,
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
> >>>
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, bu
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 u
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 objec
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
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 s
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 b
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 slo
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 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 ch
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
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:
> > 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
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 r
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 rea
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 his
33 matches
Mail list logo
