Re: [FreeBSD-tech-jp 2988] Re: Unicode support in cd9660 [patch for review]
On Wed, 27 Dec 2000 21:28:19 +0900, Motomichi Matsuzaki [EMAIL PROTECTED] said: msaki Any ideas? There was dicussion about this issue on [EMAIL PROTECTED] mailing list with Subject: "Unicode support in kernel" and "code set recoding engine, V2" in October and November, 1999. Summary of my proposal is the following: http://mail-index.netbsd.org/tech-kern/1999/10/15/0009.html http://mail-index.netbsd.org/tech-kern/1999/11/23/0002.html (the former one is somewhat difficult, though) -- soda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [FreeBSD-tech-jp 2990] Re: Unicode support in cd9660 [patchfor review]
On Wed, 27 Dec 2000 21:48:52 +0900 (JST), Kenichi Okuyama [EMAIL PROTECTED] said: okuyamak So, there's only two selection. No. there is another one. I.e. 3) Always use pair of "codeset" name and "codepoint" value for interface. This keeps compatibility with current filesystems which use legacy encodings like ISO-8859-1 or EUC-JP as pathnames. My proposal follows this course. -- soda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999 10:41:23 +0100 (BST), Doug Rabson d...@nlsystems.com 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 continue a flamewar). Can people please just drop the subject until after Usenix. This kind of flamewar is too upsetting (to me anyway) and just makes it harder to have a useful face-to-face discussion. As I said earlier, I agree with you. About human factor, I think face to face communication is best way to solve problem. But about technical issues, I'd like to reply in public place, because both the message from Julian (*1) and the message from Daniel (*2) showed typical misunderstanding about newconfig. The goal they showed is also the goal of the dynamic configuration of newconfig from the beggining. I'd like to show how it will be achieved by newconifg. Could you permit me to answer technical issues in -hackers as Daniel adviced ? Or, -current is better about the questions which is posted to -current ? Other possibility is newconfig mailig list (anyone can subscribe 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 jul...@whistle.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: pine.bsf.3.95.990512165327.22596i-100...@current1.whistle.com (*2) From: Daniel C. Sobral d...@newsguy.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Fri, 14 May 1999 20:46:05 +0900 Message-ID: 373c0cfd.7d9d3...@newsguy.com -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Sat, 15 May 1999 15:58:01 +0100 (BST), Doug Rabson d...@nlsystems.com 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. Julian, Daniel, and other folks, is this OK for you? If you'd like to hear the answer now, please request us that we should reply to your question. We'll reply to you in newconfig mailing list (i.e. To: you, Cc: newconfig) to avoid useless flame war. Note that the newconfig mailing list is truly open, anyone who is interested in newconfig approach can access the answer. The address of mailing list: newcon...@jp.freebsd.org The official WWW page: http://www.jp.freebsd.org/newconfig/ The way to subscribe (majordomo): http://www.jp.freebsd.org/newconfig/ml.html The mail archive of newconfig: http://home.jp.freebsd.org/mail-list/newconfig/ The mail archive of newconfig-jp (written in Japanese): http://home.jp.freebsd.org/mail-list/newconfig-jp/index.html.ja.jis (The traffic of newconfig mailing list is not much, because main discussion is currently done in newconfig-jp.) And, Dainel, I'm very sorry that one of us called your serious question joke. I know your question is serious, because what you said is also the goal for me from the beginning of dynamic configuration of newconfig. Perhaps we should answer to you in newconfig mailing list (To: you, cc: newconfig). Is this OK for you? We have answer which satisfy your requirement. -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
These problems are all well understood and EASY TO FIX. in page 502. As this shows, it is apparent that newconfig can cope with dynamic configuration, why do new-bus people thought that newconfig cannot deal with dynamic configuration, and reinvent configuration framework? It is obvious that they do not know about newconfig enough, (their terminology like ivar shows this fact). [d] shifts the all the problems to users (e.g. see compatibility problem mentioned above) All of above facts are already told to one of the FreeBSD core members, just before core members officialy decided to choose new-bus. I do not know why core members decide new-bus, though. P.S. It seems FreeBSD already start to choose [b]. Please look at changes in revision 1.67 of sys/i386/isa/npx.c. It hardcodes magic number 13, instead of the value gotton from configuration framework. It is interesting that even this doesn't use #define NPXIRQ 13. :-) 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 Nakagawa-san, though Nakagawa-san never agreed that it is right, and rather likes the newconfig way like below: pcic0 at isa? port 0x3e0 pcic1 at isa? port 0x3e2 pcic* at pci? pcic* at isapnp? It is apparent which is better and cleaner for me. But perhaps you do not agree with me. :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
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 discuss these issues in person at Usenix. 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. -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 09:35:36 -0400, Rick Whitesel rwhite...@nbase-xyplex.com 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 drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 17:45:45 +0200, Poul-Henning Kamp p...@critter.freebsd.dk 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 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 the console driver failed. - There should be a way to inform kernel about inter module dependency dynamically. config(8) converts this information to a file which is kernel readable format. - There should be a way to inform kernel about mapping from device name to driver filename dynamically. config(8) converts this information to a file which is kernel readable format. - To achieve better performance in both UP and SMP cases. Proper SMP implementation requires fine grained locking, though this increases performance penalty in UP case. (e.g. Solaris shows this problem.) Thus, the way to specify options SMP is needed to use (static) source level and compiler level optimization. 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. The new-bus doesn't have these features. We are working on FreeBSD as a OS for the future, not for the past. Of course! We never should go back to the age of 1979 (i.e. before 4.0BSD). -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
misunderstanding. The struct cfdata can be generated via both static and dynamic way. There is no static device framework in newconfig from the first since 4.4BSD. Note that the structure of the parent vector and locator vector are changed from NetBSD's format. But this is well known problem (cgd already mentioned this several years ago), and doesn't affect any device drivers. Only configuration engine (kern/subr_autoconf.c) should be slightly modified. And it is quite trivial. This is what 4.4BSD red daemon book said that all well understood and easy to fix. Do you deny this description of the daemon book ? -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 14:53:31 -0700, Jordan K. Hubbard j...@zippy.cdrom.com 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 it were somehow part of the objective to get this feature in before a public event, it simply came up that Peter had the time to actually integrate new-bus from the Alpha platform to the x86 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 ? :-) Whether new-bus or newconfig is better was really, honestly not the issue so much as were the following two bullet points: Quite interesting. This means that FreeBSD doesn't choose technology by it's design, but by which spokes loudly. I definitely say that this is worst way to design software. 1. Does this bring the alpha and x86 architecture ports into better alignment so that any future permutations can be more easily brought across and/or simply shared between the two platforms? BSD/OS, NetBSD and OpenBSD are all based on newconfig on various architectures. FreeBSD/alpha is directly derived from NetBSD/alpha and NetBSD/alpha is based on newconfig. And at the time when the decision is made, FreeBSD/i386 and FreeBSD/pc98 are already converted to newconfig. So this is definitely is not the reason. 2. Have we had a good history of communications between the people doing new-bus vs our history of communication with the newconfig people? Have you ever asked to newconfig people? No, no one of core members who takes charge of kernel part contacted to newconfig people, ever. Only one communication is held between one of core members who is actually new-bus one, and newconfig people. And this is requested by newconfig people, not by one of core members. Note that there are core members who supports new-bus, everytime this issue is raised between core, new-bus people can reply about this, newconfig people never have that chance. If you'll make offical decision, always you can call both people, and can hear both opinion. But this is never done. The latter point is actually *really important* since we've already learned that having totally separate groups who talk to us maybe once a month (if even that often) is just not a workable strategy for the long term and often causes more confusion for our users than it actually helps the project. We talk to Doug Rabson on a practically daily basis on a wide variety of issues whereas the only real communication I've seen from you has been during this conflict. And did you call one of the newconfig people? No. The contact address of newconfig people is already publically announced, but no one of core who takes charge of kernel part contacted to the address. We contacted to the one of core who takes charge of kernel part, and talked all problem about new-bus, before the decision is made. So, which does effort of communication ? Before that, I had no idea that a Noriyuki Soda even existed. :-) Actually I am not a FreeBSD person, but one of observers of newconfig project. Some of you does know that my name is listed in NetBSD contributer's list. Although I send-pr'ed to FreeBSD sometimes. This is the reason I never posted to this mailing list. The reason I posted now is I am disgusted in FUD about technical points of newconfig. (I don't really care non technical points.) All of core should know about the benefit of the newconfig, because we already talked about it to one of the core when the decision is made. The reason why real newconfig people doesn't appears here is that there is language barrier. How did you think about Nakagawa-san's English? Do you know the pain about writing English when he knows his English is actually quite broken? (Yes, my English is broken, too. But probably I am a person who don't know what is disgrace. This is rare character and not thought good in Japan.) Can you write Japanese ? If no, why do you blame the one who cannot write English. Actually they will write English, if one of the core asked it. But no one of core request it, ever. So why no one never stops the FUD like the later postings ? To try and put it another way, I've seen a lot of arguing about the technical merits of the two systems but very little arguing about how to solve the HUMAN FACTORS aspect of this situation which are really and truly what led up to the core team's decision. I've also called for greater communication between the two groups and so far all I've seen is a lot of arguing and expressions of general annoyance from Japan - that is NOT communication! Please point out the general annoyance from Japan. If you read it carefully, you can find the technical point is correct
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 15:09:05 -0700, Mike Smith m...@smith.net.au 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 format of files file which path is known by kernel. - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. 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. Apparently you misunderstand newconfig, too. :-) See above. The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. This is a transient implementation issue, the obsolecesnce of which is already manifest in the plans that have been laid for a device identifier to module to file lookup with the translation data _outside_ the kernel. In other words, that is not compatible with the BSD way where FreeBSD and BSDI and NetBSD and OpenBSD already probed. It is actually true that FreeBSD becomes Linux. -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
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 of the message
