On Wed, 21 Apr 1999 p...@originative.co.uk wrote:
> > -Original Message-
> > From: Peter Wemm [mailto:pe...@netplex.com.au]
> > Sent: 20 April 1999 21:20
> > To: Doug Rabson
> > Cc: Takanori Watanabe; freebsd-current@freebsd.org
> > Subject: Re: new
> -Original Message-
> From: Peter Wemm [mailto:pe...@netplex.com.au]
> Sent: 20 April 1999 21:20
> To: Doug Rabson
> Cc: Takanori Watanabe; freebsd-current@freebsd.org
> Subject: Re: newbus and modem(s)
>
>
> Doug Rabson wrote:
> > On M
What about creating a second bus, isa_s, for ISA self probing?
Nick
On Wed, 21 Apr 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Peter Wemm wrote:
> [..]
> > > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > > so they don't need to explicitl
On Wed, 21 Apr 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Peter Wemm wrote:
> [..]
> > > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > > so they don't need to explicitly name the children. On one hand it could
> > > look at the hints tabl
Doug Rabson wrote:
> On Mon, 19 Apr 1999, Peter Wemm wrote:
[..]
> > Now what I'm curious about is how to handle the nexus and isa/eisa better
> > so they don't need to explicitly name the children. On one hand it could
> > look at the hints table to see all the 'at nexus?' declarations, but I
> >
On Mon, 19 Apr 1999, Peter Wemm wrote:
> > >
> > > I don't think I understand. The DRIVER_MODULE declaration goes in the
> > > downstream driver, not the upstream bus. The bus doesn't need any
> > > knowledge of what drivers might be attached to it.
> >
> > Well, what about the i386 nexus? It s
Subject: Re: newbus and modem(s)
As Rick Whitesel wrote ...
> Hi:
> Just wanted to say that I think the lack of a free-for-all CVS is
> exactly what is required to consistently move FreeBSD forward. If someone
Free-for-all as in 'everybody can do commits' ?
This is a joke I
As Rick Whitesel wrote ...
> Hi:
> Just wanted to say that I think the lack of a free-for-all CVS is
> exactly what is required to consistently move FreeBSD forward. If someone
Free-for-all as in 'everybody can do commits' ?
This is a joke I hope. There already exists such a thing. It is call
> All 'source code' control is guarded by a certain group of people in
> *every* project, and FreeBSD is no different. It just has different
> folks guarding it, who have different standards and requirements.
Perhaps a good step towards understanding would be if those
"guarding" the process would
rald Hicks
To: Alex Zepeda
Cc: Brian Feldman ; Daniel C. Sobral ;
Jordan K. Hubbard ; current ;
Sent: Monday, April 19, 1999 12:56 PM
Subject: Re: newbus and modem(s)
> > I saw this and just had to note something to you. THINK what branch you
> > are using. This is _WHERE_
> FreeBSD is somewhat of a closed development enviroment what
> some organizations do is that they maintain their own cvs repository.
FreeBSD is no more closed than "linux" is, which is touted as the most
open development project that exists.
Joe Average person can no more commit can't commit co
FreeBSD is somewhat of a closed development enviroment what
some organizations do is that they maintain their own cvs repository.
CVS repository is guarded by the core members and only "certified"
committers are allowed to commit code that in addition to not having
a procedure or a processs to mi
> > I saw this and just had to note something to you. THINK what branch you
> > are using. This is _WHERE_ things are being aired publically, and merged
> > eventually to the STABLE branch.
>
> Gosh, thank you, without your wonderful help and understanding, I NEVER
> would have been able to realize
> And then what about newconfig? To me this just adds more truth to the
> whole /. argument that *BSD promotes a closed development model.
It's a flawed argument and one that doesn't acknowledge, at least in
the case of FreeBSD, the existence of publicly accessible CVS repositories
along with the
In message <19990419124505.62d951...@spinner.netplex.com.au>, Peter Wemm wrote:
>Never mind, I understand now. :-)
Ok, I think I also understand.
The DRIVER_MODULE() macro is consist for static configuration to kick
module initialization routine for every driver.Is it correct?
But are ther more
Peter Wemm wrote:
> Doug Rabson wrote:
> > On Mon, 19 Apr 1999, Takanori Watanabe wrote:
> >
> > > In message
> , Do
> > > ug Rabson wrote:
> > > >On Mon, 19 Apr 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote:
> > > >> Simple Question.
> > > >> If there were 'Closed'-Host-Controller-I
Let me try to post an example to see whether I understood your question:
Let's assume we have a motherboard with an ISA NHCI (new host controller
interface) apart from the standard PCI UHCI (Universal Host Controller
Interface, Intel) available in the 82371AB chipset.
We boot the system, the UH
Doug Rabson wrote:
> On Mon, 19 Apr 1999, Takanori Watanabe wrote:
>
> > In message
, Do
> > ug Rabson wrote:
> > >On Mon, 19 Apr 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote:
> > >> Simple Question.
> > >> If there were 'Closed'-Host-Controller-Interface with object-only driver
> Simple Question.
> If there were 'Closed'-Host-Controller-Interface with object-only driver,
> Can the vendor make the Host controller recognized without changing
> usb.c code?
If he exports a USB bus with the appropriate methods, he will be able to
drop it in, yes. You might have noticed
On Mon, 19 Apr 1999, Takanori Watanabe wrote:
> In message ,
> Do
> ug Rabson wrote:
> >On Mon, 19 Apr 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote:
> >> Simple Question.
> >> If there were 'Closed'-Host-Controller-Interface with object-only driver,
> >> Can the vendor make the Host con
In message , Do
ug Rabson wrote:
>On Mon, 19 Apr 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote:
>> Simple Question.
>> If there were 'Closed'-Host-Controller-Interface with object-only driver,
>> Can the vendor make the Host controller recognized without changing
>> usb.c code?
>>
>> #T
On Mon, 19 Apr 1999 takaw...@shidahara1.planet.sci.kobe-u.ac.jp wrote:
> In message , Nick
> Hibm
> a wrote:
> >> Why would I say it wasn't ready? Because outside of core (apparently),
> >> nobody was warned/told that this was going to be committed in a few
> >> days/hours/minutes.
>
> >I've por
Alex Zepeda wrote:
> On Sun, 18 Apr 1999, Brian Feldman wrote:
>
> > I saw this and just had to note something to you. THINK what branch you
> > are using. This is _WHERE_ things are being aired publically, and merged
> > eventually to the STABLE branch.
>
> Gosh, thank you, without your wonderfu
On Sun, 18 Apr 1999, Alex Zepeda wrote:
> On Sun, 18 Apr 1999, Brian Feldman wrote:
>
> > I saw this and just had to note something to you. THINK what branch you
> > are using. This is _WHERE_ things are being aired publically, and merged
> > eventually to the STABLE branch.
>
> Gosh, thank you,
On Sun, 18 Apr 1999, Brian Feldman wrote:
> I saw this and just had to note something to you. THINK what branch you
> are using. This is _WHERE_ things are being aired publically, and merged
> eventually to the STABLE branch.
Gosh, thank you, without your wonderful help and understanding, I NEVER
On Sun, 18 Apr 1999, Alex Zepeda wrote:
> On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
>
> > I think CAM is a very bad example. We *still* don't have all the
> > drivers we had, and that includes at least one reasonably requested
> > driver.
>
> Is that an offer to write the missing drivers?
>
In message , Nick Hibm
a wrote:
>> Why would I say it wasn't ready? Because outside of core (apparently),
>> nobody was warned/told that this was going to be committed in a few
>> days/hours/minutes.
>I've ported the newconfig style USB code of NetBSD to FreeBSD and I
>really prefer the newbus sty
> Why would I say it wasn't ready? Because outside of core (apparently),
> nobody was warned/told that this was going to be committed in a few
> days/hours/minutes.
The USB code has been using newbus for over 4 months now. And up to now
we've had only one bug to fix. The rest was feature requests.
Alex Zepeda wrote:
>
> On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
>
> > I think CAM is a very bad example. We *still* don't have all the
> > drivers we had, and that includes at least one reasonably requested
> > driver.
>
> Is that an offer to write the missing drivers?
Is that sidetracking
> And then what about newconfig? To me this just adds more truth to the
> whole /. argument that *BSD promotes a closed development model.
I think your perceptions are fundamentally flawed here, it's just that
simple. You can argue the point all you like in -current, but it
won't change that fac
> Which means that it perhaps should be worked out before being merged. Take
> for instance CAM. It didn't work perfectly, but it sure got a lot more
> exposure than newbus, and when it was integrated it caused very few
> problems.
The two systems aren't equivalent so it's not really correct to m
On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
> I think CAM is a very bad example. We *still* don't have all the
> drivers we had, and that includes at least one reasonably requested
> driver.
Is that an offer to write the missing drivers?
> On the other hand, I don't see we losing anything with
Alex Zepeda wrote:
>
> Which means that it perhaps should be worked out before being merged. Take
> for instance CAM. It didn't work perfectly, but it sure got a lot more
> exposure than newbus, and when it was integrated it caused very few
> problems.
I think CAM is a very bad example. We *stil
> > The first thing I noticed was the panic I got, in atkbd_isa_intr, which
> > has since been fixed.
>
> Well, that is what you have to expect when running current. You are a
> betatester, and you can't expect the authors to have access to every
> combination of hardware.
Well that's my point.
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote:
> > I'm as excited as anyone to see progress, especially if it means the
> > ability to modularize the kernel and load various drivers on demand. But,
> > alas, it seems this whole thing was rushed horribly.
>
> Not at all, it's simply something whic
Doug Rabson wrote:
>
> I'm not sure about pnp but this patch should fix the overflows (not
> tested):
Seems to work fine for me (I had the sio overflow problems too).
> Index: sio.c
> ===
> RCS file: /home/ncvs/src/sys/isa/sio.c,v
>
> I'm as excited as anyone to see progress, especially if it means the
> ability to modularize the kernel and load various drivers on demand. But,
> alas, it seems this whole thing was rushed horribly.
Not at all, it's simply something which will require some time to work
out the details of in -c
On Sat, 17 Apr 1999, Alex Zepeda wrote:
> I'm as excited as anyone to see progress, especially if it means the
> ability to modularize the kernel and load various drivers on demand. But,
> alas, it seems this whole thing was rushed horribly.
>
> The first thing I noticed was the panic I got, in
On Sat, 17 Apr 1999, Alex Zepeda wrote:
> I'm as excited as anyone to see progress, especially if it means the
> ability to modularize the kernel and load various drivers on demand. But,
> alas, it seems this whole thing was rushed horribly.
>
> The first thing I noticed was the panic I got, i
39 matches
Mail list logo
