> #I'm busy recently, and shocked by suddenly new-bus merge
> #happening (I think, its process is not fair). I was lost my head.
> #Also, one of stress cause is language barrier. English is hard
> #for me. It is my weak point.
Not a problem; most of us do not speak Japanese. :-)
I am looking forw
> I replied to this in private, but, for the record, it was not a
> joke.
Ok, I see your say. I feel inadequate metaphor and provocation
form, so that message seemed vulgar joke.
New-bus's goal is meaningful, but not only that one. Also
newconfig is same. Difference between these is realization w
> On Sat, 15 May 1999 15:58:01 +0100 (BST),
Doug Rabson said:
> I would like to postpone until after Usenix. I'm sure that we will be able
> to sort out any technical misunderstandings there which will make it
> possible to have a reasonable public discussion.
OK, I'll postpone, then
On Sat, 15 May 1999, Noriyuki Soda wrote:
> > On Thu, 13 May 1999 10:41:23 +0100 (BST),
> Doug Rabson said:
>
> > As I suspected, a massive flamewar has happened while I've been away. I
> > don't think I have anything to add to what has been said (and I certainly
> > don't want to cont
ubscribe it
and it's archive can be accessed from WWW), or postponement until
after Usenix.
How do you think?
(*1)
Date: Wed, 12 May 1999 17:08:10 -0700 (PDT)
From: Julian Elischer
Subject: Re: cvs commit: src/sys/pci pcisupport.c
Message-ID:
(*2)
From: "Daniel C. Sobral"
Subject: Re: c
On Sat, 15 May 1999, Daniel C. Sobral wrote:
> Tomoaki NISHIYAMA wrote:
> >
> > From: NAKAGAWA Yoshihisa
> > y-nakaga> > You bought a computer with the super-ultra-new Microsoft (tm)
> > y-nakaga> > Microsoft Bus (tm), for which you bought the latest and greatest
> > y-nakaga> > device X.
> > y-
Tomoaki NISHIYAMA wrote:
>
> From: NAKAGAWA Yoshihisa
> y-nakaga> > You bought a computer with the super-ultra-new Microsoft (tm)
> y-nakaga> > Microsoft Bus (tm), for which you bought the latest and greatest
> y-nakaga> > device X.
> y-nakaga>
> y-nakaga> It is extremely vulgar joke. I doubt you
From: NAKAGAWA Yoshihisa
y-nakaga> > You bought a computer with the super-ultra-new Microsoft (tm)
y-nakaga> > Microsoft Bus (tm), for which you bought the latest and greatest
y-nakaga> > device X.
y-nakaga>
y-nakaga> It is extremely vulgar joke. I doubt your character.
No, I don't think this is
> You bought a computer with the super-ultra-new Microsoft (tm)
> Microsoft Bus (tm), for which you bought the latest and greatest
> device X.
It is extremely vulgar joke. I doubt your character.
--
NAKAGAWA, Yoshihisa
y-nak...@nwsl.mesh.ad.jp
nakag...@jp.freebsd.org
To Unsubscr
David Schwartz wrote:
>
> Believe it or not, good ideas can even come from people who can't
> code at
> all, and the ideas are just as good. Slapping these people down just ensures
> they don't contribute in the future.
>
> Now if their ideas genuinely are bad, you are more than
NAKAGAWA Yoshihisa wrote:
>
> > Then explain to us why newbus is wrong and why the 4.4BSD scheme is
> > right.
>
> Because, you are misunderstanding 4.4BSD scheme (and newconfig).
The *GOAL* here is the following:
You bought a computer with the super-ultra-new Microsoft (tm)
Microsoft Bus (tm),
>> In article ,
Dag-Erling Smorgrav writes:
> Any chance of getting a preview of that paper? Is it, or will it be,
> available on the Web?
Nakagawa-san slightly misunderstands. I have no time to write full
paper, so I have already submitted presentation slide.
Instead of it, I will
Mikhail Teterin wrote:
>
> Mike Smith once wrote:
>
> > For a usable dynamic architecture, loadable modules need to be
> > compiled to support both UP and SMP architectures simultaneously. Thus
> > the locking primitives need to be conditionalised at _runtime_.
>
> What about
>
>
> Any chance of getting a preview of that paper? Is it, or will it be,
> available on the Web?
I don't know, probably the paper not yet available on Web. Please
ask to Furuta-san.
--
NAKAGAWA, Yoshihisa
y-nak...@nwsl.mesh.ad.jp
nakag...@jp.freebsd.org
To Unsubscribe: send mail t
NAKAGAWA Yoshihisa writes:
> OK OK, you are right. I have language barrier, so I can't explain
> well. I talk other newconfig member, one of member, Furuta-san
> will go to Usenix and presentation of newconfig paper.
Any chance of getting a preview of that paper? Is it, or will it be,
available o
> This is pointless. All you're doing is pointing your finger and
> screaming "It's not right! It's not fair!" without saying anything of
> actual value.
OK OK, you are right. I have language barrier, so I can't explain
well. I talk other newconfig member, one of member, Furuta-san
will go to Usen
NAKAGAWA Yoshihisa writes:
> > Then explain to us why newbus is wrong and why the 4.4BSD scheme is
> > right.
> Because, you are misunderstanding 4.4BSD scheme (and newconfig).
This is pointless. All you're doing is pointing your finger and
screaming "It's not right! It's not fair!" without sayin
On Wed, 12 May 1999, Noriyuki Soda wrote:
> > > BTW, there are many fundamental design flaws in new-bus, so I don't
> > > think new-bus is comparable with newconfig, yet, even if priority
> > > probe is implemented. For example:
> >
> > I'm not going to reply to these points as I suspect it will
From: "Jordan K. Hubbard"
Subject: Re: cvs commit: src/sys/pci pcisupport.c
Date: Wed, 12 May 1999 17:12:05 -0700
Message-ID: <67065.926554...@zippy.cdrom.com>
jkh> I have seen a lot of arguing about technical merits and decisions made
jkh> by the core team, but
From: Peter Wemm
Subject: Re: cvs commit: src/sys/pci pcisupport.c
Date: Thu, 13 May 1999 06:24:12 +0800
Message-ID: <1999051414.e2dda1...@spinner.netplex.com.au>
peter> What on earth is the locator stuff for? Why can't you use plain text?
peter> How does 'iobase 0x28
In message <199905122048.qaa72...@misha.cisco.com> Mikhail Teterin writes:
: Perhaps, the newbus vs. newconfig discussion can be summarized to both
: sides' satisfaction offline and then presented to the rest of the world?
It is my impression that the language barrier has made this discussion
ha
In message <199905120901.saa04...@srapc288.sra.co.jp> Noriyuki Soda writes:
: This reminds me another ugly kluge in sys/pccard/i82365.h:
: #define PCIC_INDEX_00x3E0
: #define PCIC_INDEX_1(PCIC_INDEX_0 + 2)
: This is the way what some clever FreeBSD people saids "right" to
: Naka
> On whose authority do you say that? Garrett is a core team member.
I heard from Asami-san, Any voting not yet for new-bus. After
that, "new-bus patch" merge is decided. new-bus merge is core
decision, but "drop static configration", ... these are not yet voted.
> Then explain to us why newbus i
> Because if it's a day of coding, you should just do it. If it's a 3
> month project, you don't waste such time, and you should communicate it.
> The time factor is judged by folks who code for a living, and maybe it's
> a little high, but not too bad. I haven't seen this rule misapplied,
> but
On Wed, 12 May 1999, David Schwartz wrote:
>
> > I have to comment on this, it's too outrageous. Several times in the
> > past, folks have written in and asked, if they wrote some particular
> > piece of software, would it get committed. They said that it was a
> > large undertaking, and that t
> I have to comment on this, it's too outrageous. Several times in the
> past, folks have written in and asked, if they wrote some particular
> piece of software, would it get committed. They said that it was a
> large undertaking, and that they wouldn't undertake it, unless there was
> general
On Thu, 13 May 1999, Noriyuki Soda wrote:
> This doesn't answer my wondering. The core members can safely postpone
> the decision after Usenix, because all of core members must know that
> both new-bus people and newconfig people will come to Freenix track.
> Who is the chair of Freeunix track ? :
On Wed, 12 May 1999, Mike Smith wrote:
> > This option should automatically select the appropriate sources
> > which is compiled into kernel, according to the source is needed
> > only in UP case, or only in SMP case, or both. This is what
> > oldconfig and newconfig does.
>
> This is, aga
Mikael Karpberg wrote:
> That would be so lovely, with a DEVFS too:
> Plug your Cool card into your pcmcia slot, and get the message on
> the sytem console that an unknown pcmcia card called "Cool", made
> by CoolMakers, Inc. Damn... not even a generic driver wanted this card.
> Pull the card
On Thu, 13 May 1999, Noriyuki Soda wrote:
>
> It is actually true that FreeBSD becomes Linux.
>
It is truely unfortunate that it comes to this..
however it has always been to me a source of great frustration to me that
Linus was able to implement a driver framework that allows a very dynamic
> This doesn't answer my wondering. The core members can safely postpone
> the decision after Usenix, because all of core members must know that
> both new-bus people and newconfig people will come to Freenix track.
I'm not sure this was adequate reason to postpone the decision either,
and like I
< said:
> Have you ever asked to newconfig people?
> No, no one of core members who takes charge of kernel part contacted
> to newconfig people, ever.
It's your responsibility to communicate with us, not the other way
around. The only way for your views to be even considered is for you
to make t
> > NetBSD people have not the same stated aim of completely eliminating
> > config, so for them it made more sense to migrate to config.new.
>
> I think it's also safe to say that because of NetBSD's interest in
> supporting 'older' hardware, it would be suicide to use a truly dynamic
> scheme
> NetBSD people have not the same stated aim of completely eliminating
> config, so for them it made more sense to migrate to config.new.
I think it's also safe to say that because of NetBSD's interest in
supporting 'older' hardware, it would be suicide to use a truly dynamic
scheme since much of
ok,
here is a reason for all this...
It has benn a common thought among the FreeBSD people I have spoken too
(and that's nearly all of the main developers, INCLUDING bill Jolitz)
that with cheaper RAM and better organosed busses teh way to go is
towards removing all static devoce information from
> > It is actually true that FreeBSD becomes Linux.
> Comments like this will only ensure that you wind up in kill files,
> mine included. They add nothing to the discussion.
I see, sorry.
--
soda
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body
It seems Mike Smith wrote:
>
> > It is actually true that FreeBSD becomes Linux.
>
> This is a childish troll, especially coming from you. If for no other
> reason, this is an excellent reason _not_ to be working with your team.
Oh boy...
Could we end this now please ??
We've made our decisi
> It is actually true that FreeBSD becomes Linux.
Comments like this will only ensure that you wind up in kill files,
mine included. They add nothing to the discussion.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> > On Wed, 12 May 1999 15:09:05 -0700, Mike Smith said:
>
> > It would appear that you don't understand the problem, as no
> > configuration technique can telepathically determine in advance which
> > new drivers you are going to load.
>
> Apparently you misunderstand newconfig. :-)
> The
> On Wed, 12 May 1999 15:09:05 -0700, Mike Smith said:
> It would appear that you don't understand the problem, as no
> configuration technique can telepathically determine in advance which
> new drivers you are going to load.
Apparently you misunderstand newconfig. :-)
There is compiled f
> On Wed, 12 May 1999 14:53:31 -0700,
"Jordan K. Hubbard" said:
>> I agree that this is better way to solve the conflicts between new-bus
>> and newconfig. Although I wondered why FreeBSD's core decide to choose
>> new-bus before Usenix.
> We didn't choose it "before USENIX" as if
> Mike Smith once wrote:
>
> > For a usable dynamic architecture, loadable modules need to be
> > compiled to support both UP and SMP architectures simultaneously. Thus
> > the locking primitives need to be conditionalised at _runtime_.
>
> What about
>
> kldload /modules/up/whatev
Mikael Karpberg wrote:
> According to Mike Smith:
> > This is actually a major defect in the newconfig design; if the kernel
> > doesn't already know about a device when it is built, it can never
> > support it.
>
> That would be so lovely, with a DEVFS too:
>
> Plug your Cool card into your pcmc
Mike Smith once wrote:
> For a usable dynamic architecture, loadable modules need to be
> compiled to support both UP and SMP architectures simultaneously. Thus
> the locking primitives need to be conditionalised at _runtime_.
What about
kldload /modules/up/whatever.ko
and
According to Mike Smith:
> This is actually a major defect in the newconfig design; if the kernel
> doesn't already know about a device when it is built, it can never
> support it.
That would be so lovely, with a DEVFS too:
Plug your Cool card into your pcmcia slot, and get the message on
the syt
> > Why should we, as a 3rd millenium OS need a static config tool ?
>
> For example,
>
> - To specify the drivers which is linked statically to kernel.
> As I said earlier, you cannot link console driver dynamically,
> If you do this, you cannot get error message when dynamic
> linking of
Noriyuki Soda wrote:
> NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing
> list, because I am a NetBSD user. :-)
Aha! Now a few things are starting to make sense...
> > > It depends on old-config, so poor mechanism. newconfig already
> > > implimented best match probe/atta
> NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing
> list, because I am a NetBSD user. :-)
>
> > > It depends on old-config, so poor mechanism. newconfig already
> > > implimented best match probe/attach.
> >
> > And a very useful mechanism it is. Which is why I implemente
> I agree that this is better way to solve the conflicts between new-bus
> and newconfig. Although I wondered why FreeBSD's core decide to choose
> new-bus before Usenix.
We didn't choose it "before USENIX" as if it were somehow part of the
objective to get this feature in before a public event,
In message <199905122048.qaa72...@misha.cisco.com>, Mikhail Teterin writes:
>Or, the core team may just say: "Because we said so" (which I think was
>already done once) and stop discussing this...
We did I think.
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org
Mikhail Teterin says:
:
: Perhaps, the newbus vs. newconfig discussion can be summarized to both
: sides' satisfaction offline and then presented to the rest of the world?
But didn't this already happen. I seem to recall a round of discussions
that went on a week before the new-bus switch. T
> On Wed, 12 May 1999 12:12:54 -0700 (PDT),
Julian Elischer said:
> The eventual aim is to have a kernel which is a very sparse skelaton,
> with very few services and drivers loaded (in fact possibly none).
This is also aim of newconfig, although console driver should be
linked stati
Dag-Erling Smorgrav once wrote:
As an outside observer, who does not understand most (all?) of the
differences involved, I must say, this will have to be an unfairly
"uphill" explanation. Because, using the style exemplified by PHK today,
the newconfig people could say something like:
My personal opinion is that static configuration is a subset of dynamic
configuration.
The eventual aim is to have a kernel which is a very sparse skelaton,
with very few services and drivers loaded (in fact possibly none).
At boot time, the needed drivers and services are loaded and configured
(
NAKAGAWA Yoshihisa writes:
> > mechanism was unacceptable -- else we would have used it years ago.
> It is not formal core decision.
On whose authority do you say that? Garrett is a core team member.
> > Our policy in all areas has been that we'd rather do the Right Thing
> > than follow the cro
> On Wed, 12 May 1999 17:45:45 +0200,
Poul-Henning Kamp said:
>> What is the definition of "config"?
> config(8)
>> Why do you want to remove it?
> Why should we, as a 3rd millenium OS need a static config tool ?
For example,
- To specify the drivers which is linked statica
From: Poul-Henning Kamp
Subject: Re: cvs commit: src/sys/pci pcisupport.c
Date: Wed, 12 May 1999 17:45:45 +0200
Message-ID: <5756.926523...@critter.freebsd.dk>
phk>
phk> >phk> >Since newconfig appears technically superior, what are the
issues that
phk> >phk>
>phk> >Since newconfig appears technically superior, what are the issues
>that
>phk> >are hindering its acceptance?
>phk>
>phk> That we want to have no "config" at all.
>
>That is too short an answer.
No, it is complete and to the point.
>What is the definition of "config"?
config
From: Poul-Henning Kamp
Subject: Re: cvs commit: src/sys/pci pcisupport.c
Date: Wed, 12 May 1999 17:17:49 +0200
Message-ID: <5598.926522...@critter.freebsd.dk>
phk> In message <003001be9c88$2669b620$d3e4b...@xyplex.com>, "Rick Whitesel"
writes
phk> :
phk> >Hi:
In message <003001be9c88$2669b620$d3e4b...@xyplex.com>, "Rick Whitesel" writes
:
>Hi:
>Since newconfig appears technically superior, what are the issues that
>are hindering its acceptance?
That we want to have no "config" at all.
--
Poul-Henning Kamp FreeBSD coreteam member
p...@f
Hi:
Since newconfig appears technically superior, what are the issues that
are hindering its acceptance?
Rick Whitesel
- Original Message -
From: Noriyuki Soda
To: Rick Whitesel
Cc: Noriyuki Soda ;
Sent: Wednesday, May 12, 1999 9:41 AM
Subject: Re: cvs commit: src/sys/pci
- Original Message -
From: Noriyuki Soda
To:
Cc:
Sent: Wednesday, May 12, 1999 5:01 AM
Subject: Re: cvs commit: src/sys/pci pcisupport.c
NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing
list, because I am a NetBSD user. :-)
> > It depends on old-config, so poor mech
> On Wed, 12 May 1999 09:35:36 -0400,
"Rick Whitesel" said:
> In general I believe that dynamic configuration of the system is
> extremely useful to both the development community and the user
> community. The development community has a much easier time if they
> can load / unload dr
> > BTW, there are many fundamental design flaws in new-bus, so I don't
> > think new-bus is comparable with newconfig, yet, even if priority
> > probe is implemented. For example:
>
> I'm not going to reply to these points as I suspect it will lead to a
> pointless flame thread. I would prefer to
On Wed, 12 May 1999, Noriyuki Soda wrote:
> NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing
> list, because I am a NetBSD user. :-)
>
> > > It depends on old-config, so poor mechanism. newconfig already
> > > implimented best match probe/attach.
> >
> > And a very useful
NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing
list, because I am a NetBSD user. :-)
> > It depends on old-config, so poor mechanism. newconfig already
> > implimented best match probe/attach.
>
> And a very useful mechanism it is. Which is why I implemented priority
> Because 4.4BSD got it wrong. It has always been the belief of the
> FreeBSD Project's management that 4.4's totally-static configuration
No! 4.4BSD mechanism is good. Newconfig already support dynamic
configuration and *good* module support (not yet merge newconfig CVS).
> mechanism was unacce
> For the sake of the thread, this got committed a day or two ago, and these
> hacks have been replaced with a low priority match.
Why do you use another mechanism of 4.4BSD ? Don't loss time and
loss inter-operability between other BSDs.
--
NAKAGAWA, Yoshihisa
y-nak...@nwsl.mesh.ad.jp
Doug Rabson wrote:
> On Tue, 11 May 1999, NAKAGAWA Yoshihisa wrote:
>
> > > I was thinking of doing this, the same as alpm and intpm:
> > >
> > > case 0x:
> > > #if NUHCI > 0
> > > return NULL;
> > > #else
> > > return "VIA blah USB controller";
> > > #endif
> >
> > It depends on old-con
On Tue, 11 May 1999, NAKAGAWA Yoshihisa wrote:
> > I was thinking of doing this, the same as alpm and intpm:
> >
> > case 0x:
> > #if NUHCI > 0
> > return NULL;
> > #else
> > return "VIA blah USB controller";
> > #endif
>
> It depends on old-config, so poor mechanism. newconfig alrea
> I was thinking of doing this, the same as alpm and intpm:
>
> case 0x:
> #if NUHCI > 0
> return NULL;
> #else
> return "VIA blah USB controller";
> #endif
It depends on old-config, so poor mechanism. newconfig already
implimented best match probe/attach.
--
NAKAGAWA, Yoshihisa
71 matches
Mail list logo
