From newsletter at piekmarketing.eu Wed Apr 1 06:41:44 2009 From: newsletter at piekmarketing.eu (Piek International Education Centre (I.E.C.)) Date: Wed Apr 1 06:42:24 2009 Subject: Newsletter PIEK International Education Center I.E.C. Message-ID: From xcllnt at mac.com Wed Apr 1 09:13:54 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 1 09:14:01 2009 Subject: On errno In-Reply-To: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Message-ID: On Mar 30, 2009, at 10:31 AM, Marcel Moolenaar wrote: > This begs the question: what is stopping us from adding new > error codes? >> kientzle@ wrote: >> POSIX does specify the range of allowable error codes >> for a lot of system calls, but not all. In my experience, >> straying outside of that causes more problems than it's >> worth. I agree that well-known system calls should not be changed willy-nilly. But what about error codes returned from GEOM or other FreeBSD-specific subsystems? >> phk@ wrote: > >> Long time ago, I proposed a scheme where a process can register >> a userland error-text buffer with the kernel. >> Whenever a system call returns with error, the kernel has the >> opportunity to write an explanatory text in the registered >> buffer (if there is one). Strings are not to be used to relay error conditions between kernel and processes. Interpretation of the string is unnecessarily hard (if not impossible) if the process wants to take corrective action. They're not even good for printing, because the process is not left in control over its own output (i18n has been mentioned). >> kientzle@ responded: >> This is the right direction: Basically, add a new variable >> that augments errno instead of extending the possible values of >> errno. Augmentation seems logical. Does anyone know if this has been done in some OS already? >> phk@ wrote: >> Don't overengineer it guys. I agree that over engineering is not a good thing, but under- engineering is worse. Handwaving real-world demands/requirements with nothing more than emotional responses that lack technical argumentation does not build the "damn best OS". Oh, and yes: I have been thinking about localization of the kernel. While I don't see this to be urgent or critical to FreeBSD itself, I can see a "market" for it. >> wollman@ wrote: >> But all this is really irrelevant if no other operating system or >> standard adopts the interface. Interfaces which are peculiar to >> FreeBSD are rarely useful. That's a very good point indeed. -- Marcel Moolenaar xcllnt@mac.com From matthew.fleming at isilon.com Wed Apr 1 09:48:08 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Wed Apr 1 09:48:15 2009 Subject: On errno In-Reply-To: References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E02930FBC@seaxch09.desktop.isilon.com> > Augmentation seems logical. Does anyone know if this has been done > in some OS already? AIX version 6.0 has a kerrno_t type which contains the 8-bit standard error code, as well as basically implementation defined bits that define where the error came from. This is for the kernel and kernel extensions; for binary and source compatibility reasons the existing interfaces could not be changed, but new interfaces used the new return type. I wasn't completely happy with the way it was done, but basically defined a 12-bit block of the kerrno_t that defined which "namespace" the error came with, and parceled out a bunch for the known AIX components with a bunch of unused ones too. So a kerrno_t looked like: (32-bit) 1b | [12 bits identifying a larger namespace like which header] | [11 bits identifying which specific error return from that header] | [8 bits for errno] (64-bit) 0xEEEE | 0x0000 | [12 bits identifying a larger namespace like which header] | [12 bits identifying which specific error return from that header] | [8 bits for errno] Using 0xEEEE was an eye-catcher, plus the error was negative. Similarly the 32-bit errors are negative, which means that functions can continue to return single positive scalars in success cases that contain meaningful information, instead of requiring a reference parameter. So e.g. kerrno.h parceled out the namespace like: __SYSVMM_BLOCK_00 0x008 __SYSPROC_BLOCK_00 0x010 __DMA_BLOCK_00 0x018 ... If a component wanted to use one "namespace" per header file, there was generally room for it. And then in each shipped header file were unique defines for each reason code, like: #define EINVAL_XMEMDMA_BADADDRESS KERROR(EINVAL, __DMA_BLOCK_00, 0x001) #define ENOENT_XMEMDMA_YOUSUCK KERROR(ENOENT, __DMA_BLOCK_00, 0x002) (non-shipped headers didn't always need to enumerate the unique error codes in the header, but instead in the source file, because the callers weren't expected to look for a specific error) The code then returned somewhat ugly looking codes like EINVAL_XMEMDMA_BADADDRESS. But they could be explicitly compared. The kernel also had an awk script that generated a .txt file that listed all the names and the hex value they were defined as; this was useful for doing lookups of whatever error codes we were looking at at the time. Something better could probably be done there. I don't recall that AIX finished out the story with user-space. But these kerrno_t's were extremely useful for debugging any component that had plumbed itself fully; no more guessing at the 23 reasons it could return EINVAL; no more wondering in which subroutine the error was produced. So yeah, it isn't perfect and there's probably a better way, but it was definitely better than nothing. Discuss. :-) Cheers, matthew From gordon at tetlows.org Wed Apr 1 09:55:30 2009 From: gordon at tetlows.org (Gordon Tetlow) Date: Wed Apr 1 09:55:37 2009 Subject: On errno In-Reply-To: References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Message-ID: <4e571dd70904010928w1900ca9ey740f256c344cdd57@mail.gmail.com> On Wed, Apr 1, 2009 at 9:13 AM, Marcel Moolenaar wrote: > Oh, and yes: I have been thinking about localization of the kernel. > While I don't see this to be urgent or critical to FreeBSD itself, > I can see a "market" for it. This is an interesting discussion in light of the recent article about the "Ugly American Programmer." Basically it says that programmers all understand English (or we can basically expect them to), so as long as the information is for programmers (user/kernel barrier qualifies in my mind), is it hugely important? http://www.codinghorror.com/blog/archives/001248.html Cheers, Gordon From xcllnt at mac.com Wed Apr 1 10:24:05 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 1 10:24:10 2009 Subject: On errno In-Reply-To: <4e571dd70904010928w1900ca9ey740f256c344cdd57@mail.gmail.com> References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> <4e571dd70904010928w1900ca9ey740f256c344cdd57@mail.gmail.com> Message-ID: On Apr 1, 2009, at 9:28 AM, Gordon Tetlow wrote: > On Wed, Apr 1, 2009 at 9:13 AM, Marcel Moolenaar > wrote: > Oh, and yes: I have been thinking about localization of the kernel. > While I don't see this to be urgent or critical to FreeBSD itself, > I can see a "market" for it. > > This is an interesting discussion in light of the recent article > about the "Ugly American Programmer." Basically it says that > programmers all understand English (or we can basically expect them > to), so as long as the information is for programmers (user/kernel > barrier qualifies in my mind), is it hugely important? Errors are never for programmers. They are for programs or users. Programs work less well on strings, especially when those strings are "designed" to be printed and thus targeted towards users. Interpretation of such error messages is just painful. On top of that, the user may want a localized message. When arguments in the discussion on i18n or l10n focus on the developer, the argument is flawed by definition and pretty much useless. Only when users are considered in such discussions will you have a meaningful discussion. Thus, when a developer claims that i18n is pointless, you know that the statement can be ignored, for it puts the developer at the center of the universe and not the user. This is still assuming that we write an OS for users and not for developers. The assumption may be false... If we were to write a compiler, the "Ugly American Programmer." article would apply. Writing an OS, I would say that it applies partially at best (one can make a distinction between operators and users, and operators tend to prefer english AFAICT). Personally I'd like to think that that we write an OS for users. -- Marcel Moolenaar xcllnt@mac.com From phk at phk.freebsd.dk Wed Apr 1 10:30:08 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed Apr 1 10:30:25 2009 Subject: On errno In-Reply-To: Your message of "Wed, 01 Apr 2009 10:23:58 MST." Message-ID: <1571.1238607005@critter.freebsd.dk> In message , Marcel Moolenaar wri tes: >Personally I'd like to think that that we write an OS for users. We write an OS for the people who can and will use an OS written by us. Absent a huge influx of translators, FreeBSD is not going to have a viable I18N footprint. Such an influx, should it happen, would most likely be rebuffed and resisted by the current developers of FreeBSD. Yes, we can dream about what we could do with 1000 full time developers under a benevolent dictatorship which unlimited financial resources. But we can also look at our current circumstances and conclude that I18N is not something we can afford at this point. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From das at FreeBSD.ORG Wed Apr 1 11:00:20 2009 From: das at FreeBSD.ORG (David Schultz) Date: Wed Apr 1 11:00:27 2009 Subject: On errno In-Reply-To: <20090331065548.GA3851@onelab2.iet.unipi.it> References: <20090331064959.GA3516@onelab2.iet.unipi.it> <96314.1238481987@critter.freebsd.dk> <20090331065548.GA3851@onelab2.iet.unipi.it> Message-ID: <20090401180026.GA39424@zim.MIT.EDU> On Tue, Mar 31, 2009, Luigi Rizzo wrote: > On Tue, Mar 31, 2009 at 06:46:27AM +0000, Poul-Henning Kamp wrote: > > In message <20090331064959.GA3516@onelab2.iet.unipi.it>, Luigi Rizzo writes: > > > > >we are probably digressing but printf in glibc has specifiers to > > >indicate which argument you want to use for each format. > > > > > >http://www.gnu.org/software/hello/manual/libc/Output-Conversion-Syntax.html > > > > > >I suppose this takes an extra pass over the format string to collect > > >the proper type info for all arguments, so it is not > > >not a dramatic change in the implementation of *printf. > > > > Yeah, we have that crap too, and you can see how messy and slow our > > printf became as a result in SVN. > > I have never run performance tests of printf, but it woudld be > definitely interesting to figure out how expensive is the parsing > of the format specifiers. The expensive part, which accounts for more than 70% of the cost of processing a format specifier, is gluing together the iovec of output fragments in stdio and writing to the stream. The actual parsing accounts for almost none of the cost; it amounts to scanning for a `%', then using a switch statement (which gcc compiles into a jump table) to process the specifiers. Most of the code for handling positional parameters lives in printf-pos.c, and it's never invoked if you don't use positional parameters. From kientzle at freebsd.org Wed Apr 1 11:33:36 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Wed Apr 1 11:33:42 2009 Subject: On errno In-Reply-To: References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Message-ID: <49D3B37F.80509@freebsd.org> >>> wollman@ wrote: >>> But all this is really irrelevant if no other operating system or >>> standard adopts the interface. Interfaces which are peculiar to >>> FreeBSD are rarely useful. > > That's a very good point indeed. PHK's suggestion of plumbing this into err(), perror() and similar functions that implicitly read errno already would help here. Tim From Alexander at Leidinger.net Wed Apr 1 23:46:56 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Apr 1 23:47:03 2009 Subject: On errno In-Reply-To: References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> <4e571dd70904010928w1900ca9ey740f256c344cdd57@mail.gmail.com> Message-ID: <20090402084616.19846py8s75ogp44@webmail.leidinger.net> Quoting Marcel Moolenaar (from Wed, 01 Apr 2009 10:23:58 -0700): > If we were to write a compiler, the "Ugly American Programmer." > article would apply. Writing an OS, I would say that it applies > partially at best (one can make a distinction between operators > and users, and operators tend to prefer english AFAICT). In my experience operators prefer a language they understand well, but this may be biased by the kind of operators I know (I work in a multi-lingual environment, but we do not use FreeBSD at work). So personally I would not distinguish between operators and users. I agree with your general opinion about i18n and think that it is not a matter of workforce, it's a matter of feasability. As soon as we have the infrastructure, translations will show up "soonish". It's not "if", it's "when". Bye, Alexander. -- Real programmers don't write in BASIC. Actually, no programmers write in BASIC after reaching puberty. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From phk at phk.freebsd.dk Wed Apr 1 23:51:59 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed Apr 1 23:52:06 2009 Subject: On errno In-Reply-To: Your message of "Thu, 02 Apr 2009 08:46:16 +0200." <20090402084616.19846py8s75ogp44@webmail.leidinger.net> Message-ID: <4915.1238655116@critter.freebsd.dk> In message <20090402084616.19846py8s75ogp44@webmail.leidinger.net>, Alexander L eidinger writes: >I agree with your general opinion about i18n and think that it is not >a matter of workforce, it's a matter of feasability. As soon as we >have the infrastructure, translations will show up "soonish". It's not >"if", it's "when". And once the novelty has worn off, we are left, as so many other operating systems, with at best 70% translation into each language. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From Alexander at Leidinger.net Thu Apr 2 02:49:27 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Apr 2 02:49:33 2009 Subject: On errno In-Reply-To: <4915.1238655116@critter.freebsd.dk> References: <4915.1238655116@critter.freebsd.dk> Message-ID: <20090402114916.170547o692pg252c@webmail.leidinger.net> Quoting Poul-Henning Kamp (from Thu, 02 Apr 2009 06:51:56 +0000): > In message <20090402084616.19846py8s75ogp44@webmail.leidinger.net>, > Alexander Leidinger writes: > >> I agree with your general opinion about i18n and think that it is not >> a matter of workforce, it's a matter of feasability. As soon as we >> have the infrastructure, translations will show up "soonish". It's not >> "if", it's "when". > > And once the novelty has worn off, we are left, as so many other > operating systems, with at best 70% translation into each language. If I adapt your reasoning to our docs, we need to delete all our translations and only keep the english one. If you are pissed off by the missing 30%, submit a patch or stick with english. That's an adaption of what we tell to people when they complain about missing stuff in unmaintained areas of src/ports. Alternatively we can disconnect languages from the system if we think there's not enough coverage. Above you also average the interest over all languages, an generalization which doesn't hold, see below. You assume we need to ship with 100% coverage in all languages. For a person which only uses 40% of one specific language, and this 40% are covered by 100%, it does not matter. If those 40% are a major part to allow to earn a person an income to feed childs and the relative other, great. Note, people which set their LANG to something else already get only a xx% translated system, e.g. KDE/GNOME are displaying a lot of stuff in other languages, but stuff which is comming from FreeBSD itself is in english, so we have the situation you describe already and users are used to it (don't tell me this does not apply because we only program an OS, it applies, as for an user it does not matter what we program, _he_ is using a complete system consisting of an OS and other stuff, not only the OS without anything else). They do their best, they enjoy their native language where it is available and try to handle english when it is not available. At some point I expect that we have some strong languages, and some not so strong languages. Which ones are which and how many languages we would have... I assume the trends regarding this for the handbook can give a hint. Bye, Alexander. -- In California they don't throw their garbage away -- they make it into television shows. -- Woody Allen, "Annie Hall" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From xcllnt at mac.com Thu Apr 2 10:32:01 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 10:32:07 2009 Subject: On i18n [was: Re: On errno] In-Reply-To: <1571.1238607005@critter.freebsd.dk> References: <1571.1238607005@critter.freebsd.dk> Message-ID: <17CC6EDA-E2F7-4BC3-B7EB-EAAA3F80A9C1@mac.com> On Apr 1, 2009, at 10:30 AM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >> Personally I'd like to think that that we write an OS for users. > > We write an OS for the people who can and will use an OS written by > us. Doesn't this ipso facto mean that FreeBSD is bound to be used by the same people who develop it? Isn't this a recipe for cliques? Aren't we then predisposed to end up in a situation where only we think we have the best OS, while being ignorant of the fact that we've made ourselves entirely irrelevant to the rest of the world? > Absent a huge influx of translators, FreeBSD is not going to have > a viable I18N footprint. True. But the huge influx will not happen if we don't open the doors and welcome i18n. Your position on it has been far from welcoming indeed. In a sense you use the lack of influx to defend your position that i18n does not have to be considered. How can you be sure that your position that i18n does not have to be considered is the direct cause of the lack of influx? > Such an influx, should it happen, would most likely be rebuffed and > resisted by the current developers of FreeBSD. Right. You block the thing you argue will not happen. That's a comfortable armchair to be arguing from :-) Maybe we should ask ourselves this: if the current developers rebuf and resist influx, isn't it time for them to hand in their commit bits and find some other project to contribute to? note: this is not a personal attack, nor do I imply anyone. It's a philosophical question that applies to me to. I assume that I will block progress some time in the future (assuming I'm not doing it already) simply because I'm too firmly stuck in old ways or fail to catch up to new developments or just because my thinking becomes incompatible with the project. Isn't it better that I move on and let FreeBSD go its separate way? -- Marcel Moolenaar xcllnt@mac.com From babkin at verizon.net Thu Apr 2 13:00:21 2009 From: babkin at verizon.net (Sergey Babkin) Date: Thu Apr 2 13:00:27 2009 Subject: On errno Message-ID: <11462013.196742.1238698769903.JavaMail.root@vms062.mailsrvcs.net> Apr 2, 2009 01:04:19 AM, [1]xcllnt@mac.com wrote: >On Apr 1, 2009 > >> On Wed, Apr 1, 2009 <[2]xcllnt@mac.com> & >> Oh, and yes: I have been thinking about localiza kernel. >> While I don't see this to be urgent or crit itself, >> I can see a "market" for it. >> >> This is an interesting discussion in light of the recent arti >> about the "Ugly American Programmer." Basically it says t >> programmers all understand English (or we can basically e them >> to), so as long as the information is for programm (user/kernel >> barrier qualifies in my mind), is it hugely > >Errors are never for programmers. They are for pr >Programs work less well on strings, especially when >are "designed" to be printed and thus targeted toward >Interpretation of such error messages is just painful. On t >that, the user may want a localized message. > >Wh >develope >useless. Onl >you have a mean There are two kinds of error messages: some are m the users, some for developers. The system messages te important for developers. The messages in the end-user app more importants for the users. Also, if the users are n computer-literate, even the translated messages look lik other hand, for teh support people it's easi messages. For the developers, the trans if someone reports about a bug in a foreign language? I've h Spanish and get no idea, what does it mean. Search through the translated messages, find i find how it maps to the English message. Sometimes the funny ch aracters get cut along the way, so searching becomes more complicated. A get even worse with more strange languages like Japanese or Ru -SB References 1. 3D"mailto:xcllnt@mac.com" 2. 3D"mailto:xcllnt@mac.com" From phk at phk.freebsd.dk Thu Apr 2 14:56:37 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Apr 2 14:56:44 2009 Subject: On i18n [was: Re: On errno] In-Reply-To: Your message of "Thu, 02 Apr 2009 10:31:44 MST." <17CC6EDA-E2F7-4BC3-B7EB-EAAA3F80A9C1@mac.com> Message-ID: <1643.1238709396@critter.freebsd.dk> In message <17CC6EDA-E2F7-4BC3-B7EB-EAAA3F80A9C1@mac.com>, Marcel Moolenaar wri tes: >> We write an OS for the people who can and will use an OS written by >> us. > >Doesn't this ipso facto mean that FreeBSD is bound to be >used by the same people who develop it? > >Isn't this a recipe for cliques? And isn't that more or less the case ? :-) It was a registration of fact, not a prescription to follow. >> Such an influx, should it happen, would most likely be rebuffed and >> resisted by the current developers of FreeBSD. > >Right. You block the thing you argue will not happen. I don't block anything, I merely record my non-belief in the viability of the concept, and advocate not unduly wasting our severely limited developer time on it. If people want to I18N the kernel, they are free to do so for all I care, as long as the source code is still readable. The thing I do try to block, is the "lets try to squeeze it into 15.72 bits and use the rest for flags" mentality, because it hurts us to no end. It is a 1970 mindset that should have no place in a general purpose kernel running on multiple megabyte RAM machines. I went a long way to push "state of the art" in this area with nmount and geom, both of which abandons the "struct+#define" model for much more flexible means. The "struct+#define" model, stems from times where disk deviced drivers allowed root to fondle their registers directly through ioctls, so magic operations like disk formatting could be done from userland without bloating the kernel. Today we tell kernels to perform complex operations, which gives complex diagnostics when they do not succeed, and therefore the solution is not a 64bit errno encoded in bitfields, but a text buffer, where a sensible diagnostic can be produced. If you don't belive me, look in netgraph, which has a nightmare facility for encoding stuff, pushing into the kernel, and decoding it again. The really funny thing here is, that if you measure the amount of code required to fold error conditions into struct+#define packing, and unfolding it again into text, you'll find that it bloats the system, relative to just writing the text in the first place. That is why I propose that programs register a buffer with the kernel, and we stick the error right there and then. That obviously raises the question of I18N and language in the kernel, and my position is: as long as dmesg(8) speaks english, the kernel speaks english. If somebody want to come up with a credible I18N model for the kernel, fine. Until such time, forget I18N in this context, because there are much bigger problems for I18N in the kernel, than this error text buffer. >Maybe we should ask ourselves this: if the current >developers rebuf and resist influx, isn't it time >for them to hand in their commit bits and find some >other project to contribute to? Marcel, if you have access to the core mail archives, you will find a lot of emails from me on the subject of retirement, retirement policies, and the lack thereof. Over history, we have had a lot of arm-chair generals cling to their commitbit, because in FreeBSD you don't even get a goldenish watch when you retire: you get nothing. Recently, a committer who have been in the project longer than me, and carried a particular important task through a decade, retired. I don't recall seeing as much as a "thanks for all the fish" from core. Personally, I hope to be able to give my reasoned advice and shrug my shoulders when it is not followed: I have always been a big believer in the principle, that committed code talks loudest. Poul-Henning FreeBSD General (3. Armchair, under the window) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From chuckr at telenix.org Fri Apr 3 09:59:30 2009 From: chuckr at telenix.org (Chuck Robey) Date: Fri Apr 3 09:59:38 2009 Subject: On errno In-Reply-To: <20090402114916.170547o692pg252c@webmail.leidinger.net> References: <4915.1238655116@critter.freebsd.dk> <20090402114916.170547o692pg252c@webmail.leidinger.net> Message-ID: <49D64082.9060202@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Poul-Henning Kamp (from Thu, 02 Apr 2009 > 06:51:56 +0000): > >> In message <20090402084616.19846py8s75ogp44@webmail.leidinger.net>, >> Alexander Leidinger writes: >> >>> I agree with your general opinion about i18n and think that it is not >>> a matter of workforce, it's a matter of feasability. As soon as we >>> have the infrastructure, translations will show up "soonish". It's not >>> "if", it's "when". >> >> And once the novelty has worn off, we are left, as so many other >> operating systems, with at best 70% translation into each language. > > If I adapt your reasoning to our docs, we need to delete all our > translations and only keep the english one. Look at the subject: wasn't this (really clearly) a discussion of error strings, and not strings in general? Aren't there always error codes available in number form, so that any user could easily translate to their own language choice, even if it's unique, or even composed of bits and pieces of 5 different languages? Using numbers allows great flexibility, using strings just complicates things mightily. Some of the stuff I've read, about supplying error subcodes makes sense, but trying to extend this argument to *all* strings is outside the pale of the argument, isn't it? Besides, application translations is already being done pretty well, KDE is an example of that, and that's a long way from dealing with our kernel. > > If you are pissed off by the missing 30%, submit a patch or stick with > english. That's an adaption of what we tell to people when they complain > about missing stuff in unmaintained areas of src/ports. Alternatively we > can disconnect languages from the system if we think there's not enough > coverage. Above you also average the interest over all languages, an > generalization which doesn't hold, see below. > > You assume we need to ship with 100% coverage in all languages. For a > person which only uses 40% of one specific language, and this 40% are > covered by 100%, it does not matter. If those 40% are a major part to > allow to earn a person an income to feed childs and the relative other, > great. > > Note, people which set their LANG to something else already get only a > xx% translated system, e.g. KDE/GNOME are displaying a lot of stuff in > other languages, but stuff which is comming from FreeBSD itself is in > english, so we have the situation you describe already and users are > used to it (don't tell me this does not apply because we only program an > OS, it applies, as for an user it does not matter what we program, _he_ > is using a complete system consisting of an OS and other stuff, not only > the OS without anything else). They do their best, they enjoy their > native language where it is available and try to handle english when it > is not available. > > At some point I expect that we have some strong languages, and some not > so strong languages. Which ones are which and how many languages we > would have... I assume the trends regarding this for the handbook can > give a hint. > > Bye, > Alexander. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWQIIACgkQz62J6PPcoOnW3ACdFdiokRdZZX4386RM3X9wdsuY SowAoJtuh6EgBc3qP8ADfduFm+cP3fCV =0ocL -----END PGP SIGNATURE----- From drosih at rpi.edu Fri Apr 3 11:02:06 2009 From: drosih at rpi.edu (Garance A Drosihn) Date: Fri Apr 3 11:02:14 2009 Subject: On errno In-Reply-To: References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Message-ID: At 9:13 AM -0700 4/1/09, Marcel Moolenaar wrote: >On Mar 30, 2009, at 10:31 AM, Marcel Moolenaar wrote: > >>This begs the question: what is stopping us from adding new >>error codes? > >>>kientzle@ wrote: >>>POSIX does specify the range of allowable error codes >>>for a lot of system calls, but not all. In my experience, >>>straying outside of that causes more problems than it's >>>worth. > >I agree that well-known system calls should not be changed >willy-nilly. But what about error codes returned from GEOM >or other FreeBSD-specific subsystems? I'll make the observation that I've seen a lot of code which calls some system routine, checks the result, and if there was an error it just returns to the caller. Thus, a new errno from GEOM may show up as coming from routines which are not FreeBSD-specific. Now, that might be a fine thing to do. I'm just saying that we can not be sure that any new errno's will *only* show up as coming from routines that are unique to FreeBSD. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From achyutkamlesh at yahoo.co.in Fri Apr 3 11:18:56 2009 From: achyutkamlesh at yahoo.co.in (Kamlesh Patel) Date: Fri Apr 3 11:19:06 2009 Subject: GSoC 2009 Project proposal Review Message-ID: <821081.71230.qm@web7703.mail.in.yahoo.com> Hi, I am applying for a FreeBSD Project ?NAND Flash driver support? in GSoC 2009. I got this group id from M. Warner Losh. I have a schedule how i am planning to finish this project in summer. Could anyone please tell me if the estimated time of the tasks or dependencies between the tasks are not correct or need modification? April 20-May 23:??? Study FreeBSD driver APIs and NAND command sets May 23-June 6:???? Write FreeBSD driver skeleton for GEOM driver. June 7-June 13:??? Implement probe and attach routines. Implement GEOM ioctls suck that diskinfo will work on the device June 14-June 20:? Implement ECC routines June 21-July 4:???? Implement and test read support July 5-July 11:??? ? Implement and test write support July 13:??? ?? ? ? ? ?? Mid term evaluation of progress July 12-July 25:?? Implement bad block support July 26-Aug 15:?? Get ufs working on the flash device, tune performance. Aug 16-Aug 22:?? Write man page for driver Aug 24th??? ????????? Final evalution Thank you in advance Kamlesh MS CS CSUS From ccna.syl at gmail.com Fri Apr 3 12:01:41 2009 From: ccna.syl at gmail.com (Sylvestre Gallon) Date: Fri Apr 3 12:01:47 2009 Subject: GSoC 2009 Project proposal Review In-Reply-To: <821081.71230.qm@web7703.mail.in.yahoo.com> References: <821081.71230.qm@web7703.mail.in.yahoo.com> Message-ID: <164b4c9c0904031140n2ec05068q4406120907bdbae0@mail.gmail.com> On Fri, Apr 3, 2009 at 7:52 PM, Kamlesh Patel wrote: > Hi, > > I > am applying for a FreeBSD Project ?NAND Flash driver support? in GSoC 2009. I got this group id from M. Warner Losh. > I have a schedule how i am planning to finish this project in summer. Could anyone please tell me if the estimated time of the tasks or dependencies between the tasks are not correct or need modification? > > > > > April 20-May 23:??? Study FreeBSD driver APIs and NAND command sets > May 23-June 6:???? Write FreeBSD driver skeleton for GEOM driver. > June 7-June 13:??? Implement probe and attach routines. Implement GEOM ioctls suck that diskinfo will work on the device > > June 14-June 20:? Implement ECC routines > June 21-July 4:???? Implement and test read support > July 5-July 11:??? ? Implement and test write support > July 13:??? ?? ? ? ? ?? Mid term evaluation of progress > July 12-July 25:?? Implement bad block support > July 26-Aug 15:?? Get ufs working on the flash device, tune performance. > Aug 16-Aug 22:?? Write man page for driver > Aug 24th??? ????????? Final evalution > > Thank you in advance > Kamlesh > MS CS CSUS > Hi, I am not a FreeBSD developer but I have got some interest in Nandflash and I've got some question for you. I found this topic interesting. How do you plan to implement this driver : do you want to develop only some flash layer or add row nand support just under geom. Have you take a look on some project like uffs (http://uffs.org/) to design the nandflash architecture ? In your timeline you do not talk about ware leveling, do you have take time to think about it ? Without wear leveling a nandflash with a common filesystem on is back will only work for one or two weeks... You don't talk about bad blocks too, how do you think you can handle them ? I hope that my question will help you :) Cheers, -- Sylvestre Gallon (http://devsyl.blogspot.com) Fifth Grade Student @ Epitech & Researcher @ LSE R&D @ Rathaxes (http://www.rathaxes.org) From ivoras at freebsd.org Sat Apr 4 08:29:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Apr 4 08:29:13 2009 Subject: GSoC 2009 Project proposal Review In-Reply-To: <821081.71230.qm@web7703.mail.in.yahoo.com> References: <821081.71230.qm@web7703.mail.in.yahoo.com> Message-ID: Kamlesh Patel wrote: > Hi, > > > > > > I > am applying for a FreeBSD Project ?NAND Flash driver support? in GSoC 2009. I got this group id from M. Warner Losh. Hi, Is this about the new JEDEC Flash standard, represented also by this product: http://www.sun.com/storage/flash/module.jsp ? (it might look like a silly question - but do you have the hardware? :) ) > July 26-Aug 15: Get ufs working on the flash device, tune performance. Do you think UFS and other non-logging file systems can work optimally on flash devices (wrt flash blcok size, mostly)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090404/669471c7/signature.pgp From kmsujit at gmail.com Sun Apr 5 04:24:39 2009 From: kmsujit at gmail.com (Sujit K M) Date: Sun Apr 5 04:24:45 2009 Subject: GSoC 2009 Project proposal Review In-Reply-To: <821081.71230.qm@web7703.mail.in.yahoo.com> References: <821081.71230.qm@web7703.mail.in.yahoo.com> Message-ID: <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> > May 23-June 6:???? Write FreeBSD driver skeleton for GEOM driver. Could you clarify why this is on the GEOM Driver. Why Not be dependent on the technology like USB/FireWire/Hot Plug. Can this be achieved by using GEOM Drivers /dev interface. > June 14-June 20:? Implement ECC routines ECC? Why Develop ECC routines. Are you specifically develop drivers that are chipset dependent. > July 26-Aug 15:?? Get ufs working on the flash device, tune performance. Why UFS? What Performance? Are you going to have Application Interface for executable. Could you specify which institution or company you are representing. From ivoras at freebsd.org Sun Apr 5 04:37:40 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Apr 5 04:37:47 2009 Subject: GSoC 2009 Project proposal Review In-Reply-To: <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> References: <821081.71230.qm@web7703.mail.in.yahoo.com> <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> Message-ID: Sujit K M wrote: >> May 23-June 6: Write FreeBSD driver skeleton for GEOM driver. > Could you clarify why this is on the GEOM Driver. Why Not be dependent > on the technology like USB/FireWire/Hot Plug. Can this be achieved by using > GEOM Drivers /dev interface. I believe this was unfortunate wording on his part - any storage driver is a GEOM driver because the GEOM device is the top-level end-point for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090405/de9d121f/signature.pgp From rwatson at FreeBSD.org Sun Apr 5 10:28:58 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Apr 5 10:29:04 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: Message-ID: On Mon, 30 Mar 2009, Rick Macklem wrote: > Well, since the last one turned out to be too easy, here's one I think is a > little tougher... > > The nfsv4 client needs to know an ip address for the machine, that can be > used by servers to do callbacks on the client. I currently use the > following, which I know isn't correct, but usually works ok: > > loopb = htonl(INADDR_LOOPBACK); > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > if (IA_SIN(ia)->sin_addr.s_addr != loopb) > return (&(IA_SIN(ia)->sin_addr.s_addr)); > } > return (NULL); > > Now, I could just make it a constant set by an rc script (argument to the > callback daemon or a sysctl variable), but that's a bother for laptops using > dhcp and similar. I think allowing an argument to the callback daemon is a > good fallback, but it would be nice if it didn't normally have to be set for > things to work ok. > > Any ideas on how to do this? > > Thanks in advance for any help, rick ps: Part of the reason that the above > loop doesn't seem to be good > enough is that it requires "options VIMAGE_GLOBALS" to build. One possibility is to connect() a socket to the server address, then call getsockaddr() to query what address the network stack is using. If the connection completed, then the address could at least send packets to the server, even if it isn't reachable from the server. (Obviously, kernel versions of the above...) Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Sun Apr 5 10:32:01 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Apr 5 10:32:08 2009 Subject: VOP_LEASE In-Reply-To: <20080412021209.W43186@desktop> References: <20080412021209.W43186@desktop> Message-ID: On Sat, 12 Apr 2008, Jeff Roberson wrote: > As far as I can tell this has never been used. Unless someone can show me > otherwise I'm going to go ahead and remove it. (A year, +/- one week, passes...) Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, and NQNFS is long-gone, I propose we revisit removing VOP_LEASE, which you proposed last year but presumably died as a result of a discussion of whether it might be useful again someday. While not a huge overhead, in practice it means a passage through the VOP vector for every I/O operation, and it certainly adds lines of code. Assuming no objections in the few days, I'll toast VOP_LEASE implementation and calls from the rest of the stack from 8.x so that it's gone before we ship 8.0. Robert N M Watson Computer Laboratory University of Cambridge From rmacklem at uoguelph.ca Sun Apr 5 12:27:47 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Apr 5 12:27:53 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: Message-ID: On Sun, 5 Apr 2009, Robert Watson wrote: > > One possibility is to connect() a socket to the server address, then call > getsockaddr() to query what address the network stack is using. If the > connection completed, then the address could at least send packets to the > server, even if it isn't reachable from the server. > I used rtalloc1() and then rt_ifa->ifa_addr, which seems adequate, as recommended by a couple of helpful folks. (I didn't bother to try and filter through weird cases like the temporary ipv6 addresses, as one person mentioned.) I put in a sysctl variable, so that this can be overridden. (I think that's pretty much what the connect() would end up doing, although I'm a tcp/ip midget, so I could be wayy wronnggg:-) If it doesn't work, it's not a big tragedy, since a non-functioning callback path just implies "don't issue delegations to the client". rick From zachary.loafman at isilon.com Sun Apr 5 13:24:36 2009 From: zachary.loafman at isilon.com (zachary.loafman@isilon.com) Date: Sun Apr 5 13:24:43 2009 Subject: VOP_LEASE In-Reply-To: References: <20080412021209.W43186@desktop> Message-ID: <20090405201048.GB6319@isilon.com> On Sun, Apr 05, 2009 at 06:31:59PM +0100, Robert Watson wrote: > > On Sat, 12 Apr 2008, Jeff Roberson wrote: > >> As far as I can tell this has never been used. Unless someone can show >> me otherwise I'm going to go ahead and remove it. > > (A year, +/- one week, passes...) > > Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, > and NQNFS is long-gone, I propose we revisit removing VOP_LEASE [...] I haven't had a chance to dig into the code, but can you explain how the v4 server is granting delegations without something like VOP_LEASE? This was actually a conversation I was going to prep for prior to BSDcan. We already have a cluster-coherent oplock mechanism for CIFS, and we were planning on trying to hook that in with v4 delegations, but our FS very much needs VOP calls to accomplish things like delegations. We can't use a local lease manager. Like I said, I need to look at code; it's very likely the existing VOP_LEASE isn't right for us, anyways. -- Zach Loafman | Staff Engineer | Isilon Systems From rmacklem at uoguelph.ca Sun Apr 5 15:45:02 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Apr 5 15:45:08 2009 Subject: VOP_LEASE In-Reply-To: <20090405201048.GB6319@isilon.com> References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> Message-ID: On Sun, 5 Apr 2009, zachary.loafman@isilon.com wrote: > > I haven't had a chance to dig into the code, but can you explain how the > v4 server is granting delegations without something like VOP_LEASE? This > was actually a conversation I was going to prep for prior to BSDcan. We > already have a cluster-coherent oplock mechanism for CIFS, and we were > planning on trying to hook that in with v4 delegations, but our FS very > much needs VOP calls to accomplish things like delegations. We can't use > a local lease manager. > Good question. At the moment my code simply assumes that nothing else in FreeBSD is doing Open/Share locks and my server just tracks them itself and, if enabled, issues delegations to clients so they can do them locally. If other things, like a CIFS server, are going to be doing them as well, I think there would need to be some sort of "Windows-like lock manager" that both/all services share. I don't know if it should live below the VFS layer (it's not a file system, but a lock manager). It almost seems like it needs its own kernel API that the varous servers use. (I'll admit, since POSIX clients just always Open/Deny_none, which means essentially "no open lock", I haven't much worried about it. There is only one Windows nfsv4 client out there and I don't know if they ever do Open/Deny other than none.) Obviously, if anything else in FreeBSD is going to be handling Open Shares, that isn't sufficient. (For those not familiar with them, Open Shares are a Windowsism where Open write/Deny write opens a file for writing, but doesn't allow anyone else to open it for writing until it is closed. I'm not a Windoze guy, so I probably didn't get that quite right, but it gives you some idea of what is being talked about. A Delegation allows a client to do the Open Shares and byte range locking locally, without talking to the server. The delegation is recalled when a conflicting Open or byte range lock shows up from another client (or something else locally on the server).) The only thing my server code currently does is provide a function that can be called to recall a delegation. It currently only gets called before a local VOP_RENAME() in my code, but should also be called before local VOP_OPEN() and VOP_REMOVE(). However, this isn't sufficient if anything other than my server is issuing Open Share locks. It's an area that definitely needs some thought. (Then, there's mandatory byte range locking. Lets not even talk about that, for now:-) > Like I said, I need to look at code; it's very likely the existing > VOP_LEASE isn't right for us, anyways. > I don't think that VOP_LEASE() would be appropriate for this, since it all happens at the time of Open. (A call before VOP_RENAME() is necessary, since the nfsv4 Open uses a directory filehandle + component name and won't work after a file is renamed, since the client only knows the old name. A call before VOP_REMOVE() would be nice, so that a client doesn't allow an Open of a file already removed. However, it'll get an ESTALE shortly after opening it, anyhow.) Long winded, but hopefully not too confused, rick From julian at elischer.org Sun Apr 5 21:25:42 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Apr 5 21:25:49 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: Message-ID: <49D98461.4000002@elischer.org> Robert Watson wrote: > On Mon, 30 Mar 2009, Rick Macklem wrote: > >> Well, since the last one turned out to be too easy, here's one I think >> is a little tougher... >> >> The nfsv4 client needs to know an ip address for the machine, that can >> be used by servers to do callbacks on the client. I currently use the >> following, which I know isn't correct, but usually works ok: >> >> loopb = htonl(INADDR_LOOPBACK); >> TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { >> if (IA_SIN(ia)->sin_addr.s_addr != loopb) >> return (&(IA_SIN(ia)->sin_addr.s_addr)); >> } >> return (NULL); >> >> Now, I could just make it a constant set by an rc script (argument to >> the callback daemon or a sysctl variable), but that's a bother for >> laptops using dhcp and similar. I think allowing an argument to the >> callback daemon is a good fallback, but it would be nice if it didn't >> normally have to be set for things to work ok. >> >> Any ideas on how to do this? >> >> Thanks in advance for any help, rick ps: Part of the reason that the >> above loop doesn't seem to be good >> enough is that it requires "options VIMAGE_GLOBALS" to build. > > One possibility is to connect() a socket to the server address, then > call getsockaddr() to query what address the network stack is using. If > the connection completed, then the address could at least send packets > to the server, even if it isn't reachable from the server. > > (Obviously, kernel versions of the above...) we ended up with him doing "whatever the connect code would have done" since as he is in fact inside the kernel, he can just do the same.. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From rwatson at FreeBSD.org Mon Apr 6 03:48:31 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Apr 6 03:48:42 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: <49D98461.4000002@elischer.org> References: <49D98461.4000002@elischer.org> Message-ID: On Sun, 5 Apr 2009, Julian Elischer wrote: >> One possibility is to connect() a socket to the server address, then call >> getsockaddr() to query what address the network stack is using. If the >> connection completed, then the address could at least send packets to the >> server, even if it isn't reachable from the server. >> >> (Obviously, kernel versions of the above...) > > we ended up with him doing "whatever the connect code would have done" since > as he is in fact inside the kernel, he can just do the same.. I figured that if the RPC layer was going to make a connection anyway, we could just query the RPC layer and ask it what address it had used. However, if the decision needs to be made earlier than that, then that doesn't make as much sense. This would mean NFS could avoid knowing about routes and interfaces, and just know about sockets and addresses. Robert N M Watson Computer Laboratory University of Cambridge From bugmaster at FreeBSD.org Mon Apr 6 04:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:07:30 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200904061106.n36B6osx061799@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From rwatson at FreeBSD.org Mon Apr 6 05:13:01 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Apr 6 05:13:08 2009 Subject: VOP_LEASE In-Reply-To: <20090405201048.GB6319@isilon.com> References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> Message-ID: On Sun, 5 Apr 2009, zachary.loafman@isilon.com wrote: > On Sun, Apr 05, 2009 at 06:31:59PM +0100, Robert Watson wrote: >> >> On Sat, 12 Apr 2008, Jeff Roberson wrote: >> >>> As far as I can tell this has never been used. Unless someone can show me >>> otherwise I'm going to go ahead and remove it. >> >> (A year, +/- one week, passes...) >> >> Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, and >> NQNFS is long-gone, I propose we revisit removing VOP_LEASE [...] > > I haven't had a chance to dig into the code, but can you explain how the v4 > server is granting delegations without something like VOP_LEASE? This was > actually a conversation I was going to prep for prior to BSDcan. We already > have a cluster-coherent oplock mechanism for CIFS, and we were planning on > trying to hook that in with v4 delegations, but our FS very much needs VOP > calls to accomplish things like delegations. We can't use a local lease > manager. > > Like I said, I need to look at code; it's very likely the existing VOP_LEASE > isn't right for us, anyways. Zach, Let me know if/when you're ready for the VOP_LEASE-axing to take place, and I'll move ahead with it. And we should perhaps add delegation/oplock/etc mechanisms to our agenda for the devsummit? Robert N M Watson Computer Laboratory University of Cambridge From rmacklem at uoguelph.ca Mon Apr 6 08:50:18 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 6 08:50:25 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On Mon, 6 Apr 2009, Robert Watson wrote: > On Sun, 5 Apr 2009, Julian Elischer wrote: > >>> One possibility is to connect() a socket to the server address, then call >>> getsockaddr() to query what address the network stack is using. If the >>> connection completed, then the address could at least send packets to the >>> server, even if it isn't reachable from the server. >>> >>> (Obviously, kernel versions of the above...) >> >> we ended up with him doing "whatever the connect code would have done" >> since as he is in fact inside the kernel, he can just do the same.. > > I figured that if the RPC layer was going to make a connection anyway, we > could just query the RPC layer and ask it what address it had used. However, > if the decision needs to be made earlier than that, then that doesn't make as > much sense. This would mean NFS could avoid knowing about routes and > interfaces, and just know about sockets and addresses. > I just took a quick look at Doug's RPC code and the socket doesn't seem to be exposed to the client side by the rpc layer, so I think that rtalloc1() is probably easier? I'd also be worried about knowing when the socket pointer is valid and in a connected state. (The rtalloc1() code only uses the one path rt->rt_ifa->ifa_addr after sanity checking that the pointers aren't null, so I don't think it will be difficult to maintain. It does imply that the code knows the route locking rules, but that just means it uses RTFREE_LOCKED(rt), so as long as that macro keeps working, it should be ok, I think.) rick From MondoBancoPosta at bancopostaonline.net Mon Apr 6 13:03:34 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 13:03:52 2009 Subject: Premio vi aspetta! Message-ID: <1239045562.43838.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From zachary.loafman at isilon.com Tue Apr 7 14:53:10 2009 From: zachary.loafman at isilon.com (zachary.loafman@isilon.com) Date: Tue Apr 7 14:53:16 2009 Subject: VOP_LEASE In-Reply-To: References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> Message-ID: <20090407214822.GA31767@isilon.com> On Mon, Apr 06, 2009 at 01:13:00PM +0100, Robert Watson wrote: > > Zach, > > Let me know if/when you're ready for the VOP_LEASE-axing to take place, > and I'll move ahead with it. I've glanced at it. I see no reason to keep it in its current form, we'll likely need something different. It's interesting to know the places where VOP_LEASE is called, but revision control systems are great for keeping a historical record of such. :) > And we should perhaps add delegation/oplock/etc mechanisms to our agenda > for the devsummit? Sure. I'll throw it on the wiki when I get a chance. Which reminds me, I should probably get around to booking .. ...Zach -- Zach Loafman | Staff Engineer | Isilon Systems From mailing at gaturkey.com Thu Apr 9 00:43:24 2009 From: mailing at gaturkey.com (Global Access Travel) Date: Thu Apr 9 00:44:05 2009 Subject: Private Shore Excursions-Turkey Message-ID: <22a404d870a4591852e8d4b2a1375a96@localhost.localdomain> [http://www.turkeycalling.us] PRIVATE SHORE EXCURSIONS- TURKEY Your cruise clients will make the best of their time in Turkey on a private shore excursion! Istanbul Kusadasi & Ephesus [mailto:incoming@gaturkey.com?subject=Private Shore Excursions- Turkey] **************************************************************************** Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. **************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. *********************************************************************************************** Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. ********************************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. This message was sent by: Global Access Incoming, Nuzhetiye cad, istanbul, besiktas 34357, Turkey Powered by iContact: http://freetrial.icontact.com To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=46043599&l=82228&s=5SJB&m=562566&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=562566&s=46043599&c=5SJB&cid=305227 From dumbbell at FreeBSD.org Thu Apr 9 03:54:19 2009 From: dumbbell at FreeBSD.org (=?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?=) Date: Thu Apr 9 03:54:25 2009 Subject: Build shared profiled library? Message-ID: <49DDCB1D.6080302@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Currently, only static profiled library are built during buildworld. Why not shared library too? I ask this because Erlang uses dlsym(RTLD_NEXT, ...): when building a profiled Erlang VM, the produced binary is static and this call fails. Thanks! - -- Jean-S?bastien P?dron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndyx0ACgkQa+xGJsFYOlMgcACfZFzo5xszDs8yuPRSp0PuFjZo iZcAoMEsQKbSCFgdOhAUxKWC7/sV+07P =EJ6Z -----END PGP SIGNATURE----- From zachary.loafman at isilon.com Thu Apr 9 10:21:01 2009 From: zachary.loafman at isilon.com (Zachary Loafman) Date: Thu Apr 9 10:21:08 2009 Subject: splice() in FreeBSD Message-ID: <20090409171613.GC9442@isilon.com> Arch - Isilon has internally been using the FreeBSD sendfile() (with modifications) and our own recvfile() in order to accomplish zero-copy read/write for the userland portions of our stack (CIFS, NDMP). However, these interfaces are limited. In particular, sendfile/recvfile prevent any other thread from dealing with the same socket until the call is complete. That's somewhat silly - it would be nicer to split the read-from-file/write-to-file portion from the read-from-socket/write-to-socket portion. That also eases some of the decisions that only the layer above can really make - for example, in the sendfile() case, you don't really know if it's appropriate to send a partial read or whether the caller really needs all the data. What we'd like is something like splice(). The Linux splice interface is documented here: http://linux.die.net/man/2/splice and the internals are discussed here: http://kerneltrap.org/node/6505 . We don't need the sillier portions of it - Isilon could care less about vmsplice()/tee(). We need the ability to shuffle data from one source to one sink, and then to turn around later and use that sink as a source. At first, I found the splice() interface a bit of an abomination, but a pipe is a somewhat natural place to act as a data staging area. If we just implemented splice alone, this wouldn't require any real VM hackery - you can imagine just shuffling mbufs through the pipe to accomplish a limited form of this (or, say, a unix domain socket). As part of this, and in order to get something upstreamable, it seems like we would need a few things: *) Agreement on syscall APIs - My initial proposal is to adopt splice verbatim. Initially the interface may not be truly zero-copy for many cases, but it's a start. It also increases portability for any Linux apps that are trying to make use of it. *) Unification of uio and mbufs somehow? Isilon currently has private patches that add *_MBUF variants for I/O VOPs (e.g. we have a VOP_READ_MBUF in addition to the standard VOP_READ). Isilon is in a somewhat unique place here - I'm not sure a general file system can handle this as easily. At the top-half, our system in many ways acts a lot like a router, so we can handle things like VOP_READ_MBUF by taking file data off our back-end (which comes in as mbufs off IB), header splitting, then just slinging the mbufs out the front-end. However, I think our *_MBUF VOP variants are actually a little gross. I would rather figure out a way to unify the uio and mbuf APIs - they're both scatter/gather lists in their own special way, then call into a single VOP. Isilon can get a limited, non-upstreamable thing working fairly quickly - we can use a unix domain socket as the intermediate buffer and use our existing *_MBUF VOPs. But it would be nice if we had some consensus going forward, then we can internally march towards something we can upstream. ...Zach -- Zach Loafman | Staff Engineer | Isilon Systems From marius at alchemy.franken.de Fri Apr 10 05:06:40 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Fri Apr 10 05:06:47 2009 Subject: memory protection and sbrk() In-Reply-To: <49D252EF.7060102@cs.rice.edu> References: <49D252EF.7060102@cs.rice.edu> Message-ID: <20090410113642.GA78551@alchemy.franken.de> On Tue, Mar 31, 2009 at 12:29:19PM -0500, Alan Cox wrote: > For as long as I can remember, FreeBSD's sbrk() has provided memory with > execute permission enabled. Before we branch for FreeBSD 8.0, I'd like > to try removing execute permission on this memory. > > On (non-PAE) i386 and a few of the embedded processors, this change will > have little tangible effect because there is no distinction in the > processor's MMU between read and execute permissions. > > On amd64, the only potential problems are likely with a very few > applications, like the JVM, that have their own internal implementation > of "malloc()" and generate code on the fly (i.e., JIT compilation). > However, I have verified that at least the Sun JVM works ok. I have > also checked that cvsup, which is based on Modula-3 and does not use the > standard malloc(), works ok. > > It's also worth noting that our standard malloc() has flip-flopped over > the last year or so in terms of whether it uses sbrk() or mmap() by > default to acquire memory. When it uses mmap(), it does not request > execute permission on the allocated memory. So, depending on whether > malloc() used mmap() or sbrk(), malloc() was returning memory with > different permissions. Consequently, I think that any application > problems due to the lack of execute permission on memory returned by > malloc() would have long since been detected. > > As a final sanity check, I would appreciate it if three kinds of users > would test the attached patch: (1) some IA64, PowerPC, and Sparc64 > users, (2) amd64-based users of "exotic" languages, like common lisp, > haskell, etc. and (3) amd64-based users of other JVMs, like kaffe. > > My plan is to commit the attached patch to HEAD on the 7th of April > unless I hear of problems. > The patch doesn't seem to cause ill effects on sparc64. Marius From cathy at sies.com Fri Apr 10 08:46:25 2009 From: cathy at sies.com (Mrs.Catharina Sies) Date: Fri Apr 10 08:46:32 2009 Subject: Contact Barr. Foxy:- Mrs. Catharina Sies Message-ID: <20090410170509.9F2CE24208D@ipx11080.ipxserver.de> Hello Dear, My name is Mrs. Catharina Sies; I am a dying woman who has decided to donate what I have to you for humanity services. I am 61 years old and I was diagnosed for cancer for about 2 years ago immediately after the death of my husband who has left me everything he worked for and because the doctors told me I will not live longer than some weeks because of my health I decided to WILL/donate the sum of USD 3, 500, 000:00 Three million five hundred thousand dollars to you for the good work of humanity and also to help the motherless and less privilege and also for the assistance of the widows. I wish you all the best and may the good Lord bless you abundantly and please use the funds well and always extend the good work to others. Here is the Contact information of my Attorney below: ABRAHAM WILLIAMS & ASSOCIATES Mr. John Foxy Esq Phone: +44-703-183-7885 Fax: +44-871-264-1453 Email: abrawillassojfoxy@gmail.com Tell him that I have WILLED USD 3,500 000.00 to you and I have also notified him. I know I don't know you but I have been directed to do this. NB: I will appreciate your utmost confidentiality in this matter until the task is accomplished as i don't want anything that will jeopardize my wishes. Sincerely, Mrs.Catharina Sies From alc at cs.rice.edu Fri Apr 10 10:20:21 2009 From: alc at cs.rice.edu (Alan Cox) Date: Fri Apr 10 10:20:30 2009 Subject: memory protection and sbrk() In-Reply-To: <20090410113642.GA78551@alchemy.franken.de> References: <49D252EF.7060102@cs.rice.edu> <20090410113642.GA78551@alchemy.franken.de> Message-ID: <49DF7FC8.1000508@cs.rice.edu> Marius Strobl wrote: > On Tue, Mar 31, 2009 at 12:29:19PM -0500, Alan Cox wrote: > >> For as long as I can remember, FreeBSD's sbrk() has provided memory with >> execute permission enabled. Before we branch for FreeBSD 8.0, I'd like >> to try removing execute permission on this memory. >> >> On (non-PAE) i386 and a few of the embedded processors, this change will >> have little tangible effect because there is no distinction in the >> processor's MMU between read and execute permissions. >> >> On amd64, the only potential problems are likely with a very few >> applications, like the JVM, that have their own internal implementation >> of "malloc()" and generate code on the fly (i.e., JIT compilation). >> However, I have verified that at least the Sun JVM works ok. I have >> also checked that cvsup, which is based on Modula-3 and does not use the >> standard malloc(), works ok. >> >> It's also worth noting that our standard malloc() has flip-flopped over >> the last year or so in terms of whether it uses sbrk() or mmap() by >> default to acquire memory. When it uses mmap(), it does not request >> execute permission on the allocated memory. So, depending on whether >> malloc() used mmap() or sbrk(), malloc() was returning memory with >> different permissions. Consequently, I think that any application >> problems due to the lack of execute permission on memory returned by >> malloc() would have long since been detected. >> >> As a final sanity check, I would appreciate it if three kinds of users >> would test the attached patch: (1) some IA64, PowerPC, and Sparc64 >> users, (2) amd64-based users of "exotic" languages, like common lisp, >> haskell, etc. and (3) amd64-based users of other JVMs, like kaffe. >> >> My plan is to commit the attached patch to HEAD on the 7th of April >> unless I hear of problems. >> >> > > The patch doesn't seem to cause ill effects on sparc64. > Thanks for the feedback. I haven't committed the patch yet because yours is the first response that I've received. At this point, I'm going to wait another 24 hours and commit the patch. Alan From des at des.no Fri Apr 10 12:25:52 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Apr 10 12:25:58 2009 Subject: Build shared profiled library? In-Reply-To: <49DDCB1D.6080302@FreeBSD.org> (=?utf-8?Q?=22Jean-S=C3=A9bast?= =?utf-8?Q?ien_P=C3=A9dron=22's?= message of "Thu, 09 Apr 2009 12:17:01 +0200") References: <49DDCB1D.6080302@FreeBSD.org> Message-ID: <86vdpcuxxu.fsf@ds4.des.no> Jean-S?bastien P?dron writes: > Currently, only static profiled library are built during buildworld. Why > not shared library too? Because - if I understand correctly how gprof works - you wouldn't be able to profile code inside the libraries, unless gprof knew enough about rtld to figure out which libraries were loaded, in which order, at which addresses, and duplicate the relocations. DES -- Dag-Erling Sm?rgrav - des@des.no From rwatson at FreeBSD.org Sat Apr 11 09:11:56 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Apr 11 09:12:03 2009 Subject: Simple #define for cache line size Message-ID: Dear all: We have a number of __aligned() qualifiers scattered around the kernel intended to space objects to improve alignment with respect to cache lines. This is important for a number of reasons, not least avoiding cache line thrashing when using arrays of foo[MAXCPU]. What I'd like to do is provide a single compile-time constant, CACHE_LINE_SIZE, defined in machine-dependent param.h, to use for spacing such objects, rather than hard-coding various values around. Here are some examples of existing spacing attempts: i386/include/pcpu.h, line 67 66 #define PCPU_MD_FIELDS \ > 67 char pc_monitorbuf[128] __aligned(128); /* cache line */ \ 68 struct pcpu *pc_prvspace; /* Self-reference */ \ kern/sched_ule.c, line 230 229 #endif > 230 } __aligned(64); 231 vm/uma_core.c, line 115 114 /* The boot-time adjusted value for cache line alignment. */ > 115 static int uma_align_cache = 64 - 1; 116 We could then deploy __aligned(CACHE_LINE_SIZE) in various places, such as on the description of per-CPU caches for UMA, to ensure that, for example, per-CPU stats for one CPU weren't in the same cache line as stats for other CPUs. NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, but I'm going with an MD definition as I suspect people will want to do different things on different architectures (and there is variation). I've defaulted all architectures to 64 bytes, but I suspect a number would prefer to use 32. Patch below. There's undoubtably an argument for doing something more optimal than what I'm proposing here, but right now I'm just looking for something that works, and would be happy to see it replaced with something more mature once it's available. Robert N M Watson Computer Laboratory University of Cambridge Index: arm/include/param.h =================================================================== --- arm/include/param.h (revision 190941) +++ arm/include/param.h (working copy) @@ -81,6 +81,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT 12 #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ #define PAGE_MASK (PAGE_SIZE - 1) Index: powerpc/include/param.h =================================================================== --- powerpc/include/param.h (revision 190941) +++ powerpc/include/param.h (working copy) @@ -79,6 +79,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT 12 #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ #define PAGE_MASK (PAGE_SIZE - 1) Index: sparc64/include/param.h =================================================================== --- sparc64/include/param.h (revision 190941) +++ sparc64/include/param.h (working copy) @@ -71,6 +71,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT_8K 13 #define PAGE_SIZE_8K (1L< References: Message-ID: <49E0C7D3.1010005@FreeBSD.org> Robert Watson wrote: > Index: arm/include/param.h > =================================================================== > --- arm/include/param.h (revision 190941) > +++ arm/include/param.h (working copy) > @@ -81,6 +81,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT 12 > #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ > #define PAGE_MASK (PAGE_SIZE - 1) > Index: powerpc/include/param.h It would be helpful to instead do: #ifndef CACHE_LINE_SHIFT #define CACHE_LINE_SHIFT 6 #endif #define CACHE_LINE_SIZE (1 << CACHE_LINE_SHIFT) In particular, src/lib/libc/stdlib/malloc.c would benefit. Thanks, Jason From nwhitehorn at freebsd.org Sat Apr 11 11:29:14 2009 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sat Apr 11 11:29:21 2009 Subject: Simple #define for cache line size In-Reply-To: References: Message-ID: <49E0D353.7090308@freebsd.org> Robert Watson wrote: > > > NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, > but I'm going with an MD definition as I suspect people will want to > do different things on different architectures (and there is > variation). I've defaulted all architectures to 64 bytes, but I > suspect a number would prefer to use 32. For what it's worth, this is per-CPU variable on PowerPC and detected at runtime. Most of the CPUs we support have 32 byte cache lines, but some (e.g. the G5) use 128 bytes. I'm not sure there is a general solution in this case, but that's the situation on PPC. -Nathan From brde at optusnet.com.au Sat Apr 11 14:10:05 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Apr 11 14:10:12 2009 Subject: Simple #define for cache line size In-Reply-To: <49E0C7D3.1010005@FreeBSD.org> References: <49E0C7D3.1010005@FreeBSD.org> Message-ID: <20090412041840.F4999@besplex.bde.org> On Sat, 11 Apr 2009, Jason Evans wrote: > Robert Watson wrote: >> Index: arm/include/param.h >> =================================================================== >> --- arm/include/param.h (revision 190941) >> +++ arm/include/param.h (working copy) >> @@ -81,6 +81,10 @@ >> #define ALIGNBYTES _ALIGNBYTES >> #define ALIGN(p) _ALIGN(p) >> >> +#ifndef CACHE_LINE_SIZE >> +#define CACHE_LINE_SIZE 64 >> +#endif >> + >> #define PAGE_SHIFT 12 >> #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ >> #define PAGE_MASK (PAGE_SIZE - 1) >> Index: powerpc/include/param.h > > It would be helpful to instead do: > > #ifndef CACHE_LINE_SHIFT > #define CACHE_LINE_SHIFT 6 > #endif > #define CACHE_LINE_SIZE (1 << CACHE_LINE_SHIFT) > > In particular, src/lib/libc/stdlib/malloc.c would benefit. It shouldn't be ifdefed, since it isn't an option and any override of the definition would tend to give binary incompatibilities, especially if it is used in userland (userland can't match kernel options or know if they are matched). FreeBSD already has too many non-options like this. CACHE_LINE_* is mainly advisory but would still cause binary incompatibilities when it is used for array sizes. Bruce From dfr at rabson.org Sun Apr 12 04:58:30 2009 From: dfr at rabson.org (Doug Rabson) Date: Sun Apr 12 04:58:38 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On 6 Apr 2009, at 16:56, Rick Macklem wrote: > > > On Mon, 6 Apr 2009, Robert Watson wrote: > >> On Sun, 5 Apr 2009, Julian Elischer wrote: >> >>>> One possibility is to connect() a socket to the server address, >>>> then call getsockaddr() to query what address the network stack >>>> is using. If the connection completed, then the address could at >>>> least send packets to the server, even if it isn't reachable from >>>> the server. >>>> (Obviously, kernel versions of the above...) >>> we ended up with him doing "whatever the connect code would have >>> done" since as he is in fact inside the kernel, he can just do the >>> same.. >> >> I figured that if the RPC layer was going to make a connection >> anyway, we could just query the RPC layer and ask it what address >> it had used. However, if the decision needs to be made earlier >> than that, then that doesn't make as much sense. This would mean >> NFS could avoid knowing about routes and interfaces, and just know >> about sockets and addresses. >> > > I just took a quick look at Doug's RPC code and the socket doesn't > seem to be exposed to the client side by the rpc layer, so I think > that rtalloc1() is probably easier? I'd also be worried about > knowing when the socket > pointer is valid and in a connected state. (The rtalloc1() code only > uses the > one path rt->rt_ifa->ifa_addr after sanity checking that the > pointers aren't null, so I don't think it will be difficult to > maintain. It does imply > that the code knows the route locking rules, but that just means it > uses RTFREE_LOCKED(rt), so as long as that macro keeps working, it > should > be ok, I think.) While the RPC code doesn't currently expose the socket or local address, I don't think there would be many problems in adding a client control operation to get the local address. Its not a good idea to allow access to the actual socket since that will change over reconnects. In theory, the local address may also change over reconnects but that seems less likely to be a problem. Also, the reconnect machinery doesn't actually create the connection until the first RPC so some care would be needed to account for that. From rwatson at FreeBSD.org Sun Apr 12 05:24:25 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Apr 12 05:24:33 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On Sun, 12 Apr 2009, Doug Rabson wrote: > While the RPC code doesn't currently expose the socket or local address, I > don't think there would be many problems in adding a client control > operation to get the local address. Its not a good idea to allow access to > the actual socket since that will change over reconnects. In theory, the > local address may also change over reconnects but that seems less likely to > be a problem. Also, the reconnect machinery doesn't actually create the > connection until the first RPC so some care would be needed to account for > that. This was pretty much what I had in mind: do an initial no-op, then query the local address from the RPC layer. The question then is, when do you requery the address, and I guess an event is needed from the RPC layer so that the NFS layer knows to re-query and update the server's callback address (I assume that's allowed?). Robert N M Watson Computer Laboratory University of Cambridge From dfr at rabson.org Sun Apr 12 06:57:29 2009 From: dfr at rabson.org (Doug Rabson) Date: Sun Apr 12 07:10:02 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On 12 Apr 2009, at 13:24, Robert Watson wrote: > On Sun, 12 Apr 2009, Doug Rabson wrote: > >> While the RPC code doesn't currently expose the socket or local >> address, I don't think there would be many problems in adding a >> client control operation to get the local address. Its not a good >> idea to allow access to the actual socket since that will change >> over reconnects. In theory, the local address may also change over >> reconnects but that seems less likely to be a problem. Also, the >> reconnect machinery doesn't actually create the connection until >> the first RPC so some care would be needed to account for that. > > This was pretty much what I had in mind: do an initial no-op, then > query the local address from the RPC layer. The question then is, > when do you requery the address, and I guess an event is needed from > the RPC layer so that the NFS layer knows to re-query and update the > server's callback address (I assume that's allowed?). There is no need for an initial no-op - the code in sys/rpc/clnt_rc.c can connect the socket on an address query as well as on the first RPC. I'm less sure about how to handle address changes, if at all. I don't think the NFSv4 spec says anything on the matter. In NFSv4.1, callbacks are multiplexed onto the same connection as for regular forward RPCs so the problem will eventually go away. From rmacklem at uoguelph.ca Sun Apr 12 11:04:26 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Apr 12 12:00:37 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On Sun, 12 Apr 2009, Doug Rabson wrote: [good stuff snipped] > > I'm less sure about how to handle address changes, if at all. I don't think > the NFSv4 spec says anything on the matter. In NFSv4.1, callbacks are > multiplexed onto the same connection as for regular forward RPCs so the > problem will eventually go away. > Address changes are problematic. If the nfsv4.0 client knows about an address change, it can do a fresh SetClientID/SetClientIDConfirm to tell the server about the new address. However, I think the safest thing for the client to do if a callback path isn't going to be stable, is to disable callbacks. (This just implies that the server won't choose to issue delegations and everything still works. To be honest, at this point, there isn't even much of a performance gain from delegations, although I am hoping to figure out how to use them to improve client side caching over the next year or so.) At this point, not starting the callback daemon (nfscbd) implies no callbacks, but I don't know of an "automagic" way to decide if the callback path will be stable. NB: A callback path that never works is just like no callbacks and isn't much of a problem. The problems occur when the callback path breaks after a while, when the client holds delegations issued to it by the server. It might be a good idea to initially ship with callbacks and delegations disabled, documenting them as "bleeding edge experimental features"? rick ps: For now, I think that using rtalloc1() if the callback address hasn't been set via sysctl, is adequate. However, if changes to the correct callback address (or knowing that the address is likely to change) can be detected, that would be nice. From rwatson at FreeBSD.org Sun Apr 12 11:12:05 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Apr 12 12:01:14 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On Sun, 12 Apr 2009, Rick Macklem wrote: >> I'm less sure about how to handle address changes, if at all. I don't think >> the NFSv4 spec says anything on the matter. In NFSv4.1, callbacks are >> multiplexed onto the same connection as for regular forward RPCs so the >> problem will eventually go away. > > Address changes are problematic. If the nfsv4.0 client knows about an > address change, it can do a fresh SetClientID/SetClientIDConfirm to tell the > server about the new address. > > However, I think the safest thing for the client to do if a callback path > isn't going to be stable, is to disable callbacks. (This just implies that > the server won't choose to issue delegations and everything still works. To > be honest, at this point, there isn't even much of a performance gain from > delegations, although I am hoping to figure out how to use them to improve > client side caching over the next year or so.) If we want to consider doing client-side disk caching, such as paging out NFS buffer cache to local swap, having delegations so we can invalidate the cache is fairly important. It becomes even more important if we want to do persistent client-side disk caching across reboots, as found in systems like AFS (does the NFSv4 design allow for this, or are client reboots still necessarily considered terminal for all caching?) The kind of scenario I have in mind isn't my IP address changing every 30 seconds, in which case NFS will be fairly useless anyway. It's more the "My IP changes twice a day when I suspend my notebook and commute to or from my office", or alternatively "My desktop is behind a NAT at home, and the ISP reboots my DSL modem once a month, which changes my ISP". In both of those scenarios, quickly noticing and re-establishing the callback path so that more effective caching can be used might make a significant difference. (Obviously, none of this really matters until delegations work...) Robert N M Watson Computer Laboratory University of Cambridge From rmacklem at uoguelph.ca Sun Apr 12 12:44:35 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Apr 12 13:24:49 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: On Sun, 12 Apr 2009, Robert Watson wrote: > > If we want to consider doing client-side disk caching, such as paging out NFS > buffer cache to local swap, having delegations so we can invalidate the cache > is fairly important. It becomes even more important if we want to do > persistent client-side disk caching across reboots, as found in systems like > AFS (does the NFSv4 design allow for this, or are client reboots still > necessarily considered terminal for all caching?) > Yes, what I am thinking of (I've coded parts of it, but always get distracted before I get it working:-) is whole file caching on local disk for delegated files, up to a certain size. And yes, if the delegation info is stored on stable storage, such as local disk, a client can recover it after a reboot. (Since no client currently does this, that part of current servers isn't heavily tested, so doing so could get "interesting":-) So, yes, I'd like to see delegations working, too. > The kind of scenario I have in mind isn't my IP address changing every 30 > seconds, in which case NFS will be fairly useless anyway. It's more the "My > IP changes twice a day when I suspend my notebook and commute to or from my > office", or alternatively "My desktop is behind a NAT at home, and the ISP > reboots my DSL modem once a month, which changes my ISP". In both of those > scenarios, quickly noticing and re-establishing the callback path so that > more effective caching can be used might make a significant difference. > The first scenario is problematic for nfsv4. If a client doesn't do a lease renewal within the server's chosen lease duration, the server has the right to throw away state, including locks and delegations. Most servers choose a lease duration of 1-2 minutes these days, so it needs to be "fast commute":-) Actually, my server chooses to be lenient and only expires state when it has to, due to a conflicting request or resource exhaustion and not just upon lease expiration, so you might be ok with a FreeBSD server, but not a Linux one (oh wait, you folks might actually consider that a feature:-). The second brings up the question of NAT, which I know diddly about. (I vaguely thought that neither rtalloc() nor getsockaddr() would work, since they would return 192.168.x.x and you really need the address assigned by the isp?) Can someone help w.r.t. what address to use when behind a NAT? Doug, maybe a client could optionally set an "upcall function" that would be called with the local ip address upon each reconnect to a server? (Then the nfsv4 client could check to see if the address had changed and do a fresh SetClientID/SetClientIDConfirm to change it, if it has?) > (Obviously, none of this really matters until delegations work...) Well, depends upon your definition of "work". At this point, they seem to function fine so long as the callback path is working and my client does do local opens and locking when it has a delegation. It doesn't yet do any clever caching and the FreeBSD kernel needs something (I am planning on posting a first stab at this in a few days) done before local VOP_RENAME() and VOP_ADVLOCK() calls to ensure consistency with locallly done ops. be added for correctness. rick From kientzle at freebsd.org Sun Apr 12 14:07:36 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Apr 12 14:43:54 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: <49E25816.9010907@freebsd.org> > The second brings up the question of NAT, which I know diddly about. > (I vaguely thought that neither rtalloc() nor getsockaddr() would work, > since they would return 192.168.x.x and you really need the address > assigned by the isp?) Can someone help w.r.t. what address to use > when behind a NAT? In general, the client doesn't know what address to use in this case. In fact, I've been a little confused by this conversation all along. It sounds like the client is looking up it's own address in order to tell the server how to contact the client? Why? The server already knows the source IP address on the incoming packets from the client; that's much more robust than anything the client could look up. Or did I misunderstand something? Tim From max at love2party.net Sun Apr 12 15:25:37 2009 From: max at love2party.net (Max Laier) Date: Sun Apr 12 16:01:58 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: <49E25816.9010907@freebsd.org> References: <49E25816.9010907@freebsd.org> Message-ID: <200904130025.31771.max@love2party.net> On Sunday 12 April 2009 23:07:34 Tim Kientzle wrote: > > The second brings up the question of NAT, which I know diddly about. > > (I vaguely thought that neither rtalloc() nor getsockaddr() would work, > > since they would return 192.168.x.x and you really need the address > > assigned by the isp?) Can someone help w.r.t. what address to use > > when behind a NAT? > > In general, the client doesn't know what address to use > in this case. In fact, I've been a little confused by this > conversation all along. It sounds like the client is > looking up it's own address in order to tell the server > how to contact the client? Why? The server already > knows the source IP address on the incoming packets > from the client; that's much more robust than anything > the client could look up. Well, the client also needs to listen at the address - that is a local decision. This is much like the problem with active mode FTP - and it has the same problems with NAT (i.e. the NAT service must be aware of the protocol and translate the address inside). The alternative is to use things like UPnP to retrieve an external address mapping ... there are libraries to deal with that. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From bugmaster at FreeBSD.org Mon Apr 13 04:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:33:10 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200904131106.n3DB6nMi084865@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From rmacklem at uoguelph.ca Mon Apr 13 07:13:50 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 13 07:48:32 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: <49E25816.9010907@freebsd.org> References: <49D98461.4000002@elischer.org> <49E25816.9010907@freebsd.org> Message-ID: On Sun, 12 Apr 2009, Tim Kientzle wrote: > > In general, the client doesn't know what address to use > in this case. In fact, I've been a little confused by this > conversation all along. It sounds like the client is > looking up it's own address in order to tell the server > how to contact the client? Why? The server already > knows the source IP address on the incoming packets > from the client; that's much more robust than anything > the client could look up. > No misunderstanding, except that the nfsv4 designers put the callback address in the SetClientID request, so a client must explicitly specify it. (I can only guess that they wanted the client to be able to specify an alternate routing or maybe some vendors wanted to be able to put the callback server on a separate machine/interface or ???) To me, it would have been simpler to just put callback RPCs in the same TCP stream as the client->server RPCs, but they didn't do that either. For nfsv4.1, there is a large glob of stuff called Sessions, which handles the transport layer and the connections for callbacks are created by the client, which avoids the problem. rick From rmacklem at uoguelph.ca Mon Apr 13 07:26:46 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Apr 13 08:23:32 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: <200904130025.31771.max@love2party.net> References: <49E25816.9010907@freebsd.org> <200904130025.31771.max@love2party.net> Message-ID: On Sun, 12 Apr 2009, Max Laier wrote: [Tim's good stuff snipped] > > Well, the client also needs to listen at the address - that is a local > decision. For now, it just listens on INADDR_ANY, but I suppose there's an argument for adding an option to the daemon to set an address, to restrict it to listening on one interface? (I do currently have a sysctl variable for overriding what rtalloc1() returns, but that requires manual intervention. There is an argument for setting the port#. Does someone have to set the port in the NAT gateway manually or is there a protocol/library for doing that? > This is much like the problem with active mode FTP - and it has the > same problems with NAT (i.e. the NAT service must be aware of the protocol and > translate the address inside). The alternative is to use things like UPnP to > retrieve an external address mapping ... there are libraries to deal with > that. > Are these libraries in FreeBSD-CURRENT? If so, please point me towards them, so I can take a look. Since the callback daemon starts out in userland, talking to userland libraries to handle NAT shouldn't be a problem. Thanks for the help sofar, rick From jhb at freebsd.org Mon Apr 13 08:29:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 08:48:44 2009 Subject: Simple #define for cache line size In-Reply-To: <49E0D353.7090308@freebsd.org> References: <49E0D353.7090308@freebsd.org> Message-ID: <200904131022.53882.jhb@freebsd.org> On Saturday 11 April 2009 1:28:51 pm Nathan Whitehorn wrote: > Robert Watson wrote: > > > > > > NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, > > but I'm going with an MD definition as I suspect people will want to > > do different things on different architectures (and there is > > variation). I've defaulted all architectures to 64 bytes, but I > > suspect a number would prefer to use 32. > For what it's worth, this is per-CPU variable on PowerPC and detected at > runtime. Most of the CPUs we support have 32 byte cache lines, but some > (e.g. the G5) use 128 bytes. I'm not sure there is a general solution in > this case, but that's the situation on PPC. > -Nathan I think UMA can handle a variable size and that should be preserved. However, for the purposes of aligned() I think a constant that is the maximum size (such as 128 on ppc) might work best. -- John Baldwin From jhb at freebsd.org Mon Apr 13 08:29:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 08:48:44 2009 Subject: Simple #define for cache line size In-Reply-To: <49E0D353.7090308@freebsd.org> References: <49E0D353.7090308@freebsd.org> Message-ID: <200904131022.53882.jhb@freebsd.org> On Saturday 11 April 2009 1:28:51 pm Nathan Whitehorn wrote: > Robert Watson wrote: > > > > > > NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, > > but I'm going with an MD definition as I suspect people will want to > > do different things on different architectures (and there is > > variation). I've defaulted all architectures to 64 bytes, but I > > suspect a number would prefer to use 32. > For what it's worth, this is per-CPU variable on PowerPC and detected at > runtime. Most of the CPUs we support have 32 byte cache lines, but some > (e.g. the G5) use 128 bytes. I'm not sure there is a general solution in > this case, but that's the situation on PPC. > -Nathan I think UMA can handle a variable size and that should be preserved. However, for the purposes of aligned() I think a constant that is the maximum size (such as 128 on ppc) might work best. -- John Baldwin From gnn at freebsd.org Mon Apr 13 12:38:02 2009 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Apr 13 13:26:40 2009 Subject: splice() in FreeBSD In-Reply-To: <20090409171613.GC9442@isilon.com> References: <20090409171613.GC9442@isilon.com> Message-ID: <7iskkcgyzr.wl%gnn@neville-neil.com> At Thu, 9 Apr 2009 10:16:13 -0700, Zachary Loafman wrote: > > Arch - > > Isilon has internally been using the FreeBSD sendfile() (with > modifications) and our own recvfile() in order to accomplish zero-copy > read/write for the userland portions of our stack (CIFS, > NDMP). However, these interfaces are limited. In particular, > sendfile/recvfile prevent any other thread from dealing with the same > socket until the call is complete. That's somewhat silly - it would be > nicer to split the read-from-file/write-to-file portion from the > read-from-socket/write-to-socket portion. That also eases some of the > decisions that only the layer above can really make - for example, in > the sendfile() case, you don't really know if it's appropriate to send > a partial read or whether the caller really needs all the data. > > What we'd like is something like splice(). The Linux splice interface > is documented here: http://linux.die.net/man/2/splice and the > internals are discussed here: http://kerneltrap.org/node/6505 . We > don't need the sillier portions of it - Isilon could care less about > vmsplice()/tee(). We need the ability to shuffle data from one source > to one sink, and then to turn around later and use that sink as a > source. At first, I found the splice() interface a bit of an > abomination, but a pipe is a somewhat natural place to act as a data > staging area. If we just implemented splice alone, this wouldn't > require any real VM hackery - you can imagine just shuffling mbufs > through the pipe to accomplish a limited form of this (or, say, a unix > domain socket). > > As part of this, and in order to get something upstreamable, it seems > like we would need a few things: > > *) Agreement on syscall APIs - My initial proposal is to adopt splice > verbatim. Initially the interface may not be truly zero-copy for many > cases, but it's a start. It also increases portability for any Linux > apps that are trying to make use of it. > > *) Unification of uio and mbufs somehow? Isilon currently has private > patches that add *_MBUF variants for I/O VOPs (e.g. we have a > VOP_READ_MBUF in addition to the standard VOP_READ). Isilon is in a > somewhat unique place here - I'm not sure a general file system can > handle this as easily. At the top-half, our system in many ways acts a > lot like a router, so we can handle things like VOP_READ_MBUF by > taking file data off our back-end (which comes in as mbufs off IB), > header splitting, then just slinging the mbufs out the > front-end. However, I think our *_MBUF VOP variants are actually a > little gross. I would rather figure out a way to unify the uio and > mbuf APIs - they're both scatter/gather lists in their own special > way, then call into a single VOP. > > Isilon can get a limited, non-upstreamable thing working fairly > quickly - we can use a unix domain socket as the intermediate buffer > and use our existing *_MBUF VOPs. But it would be nice if we had some > consensus going forward, then we can internally march towards > something we can upstream. > I like the idea, though I don't know if I like the name "splice" because to me it's a bit confusing, but we're probably stuck with the name since it's already in use. If/when you have patches send them along next. Best, George From ivoras at freebsd.org Mon Apr 13 14:02:13 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Apr 13 14:51:20 2009 Subject: Simple #define for cache line size In-Reply-To: References: Message-ID: Robert Watson wrote: > --- i386/include/param.h (revision 190941) > +++ i386/include/param.h (working copy) > @@ -74,6 +74,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif Wouldn't it be better to continue the cpu I486_CPU cpu I586_CPU cpu I686_CPU series of defines in kernel configuration and define alignment per CPU architecture? I guess it depends on the trends - are cache lines expected to change in the near future? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090413/aff49596/signature.pgp From julian at elischer.org Mon Apr 13 15:13:15 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Apr 13 15:46:04 2009 Subject: getting a callback ip address for nfsv4 client In-Reply-To: References: <49D98461.4000002@elischer.org> Message-ID: <49E3B4D5.3070701@elischer.org> Doug Rabson wrote: > > While the RPC code doesn't currently expose the socket or local address, > I don't think there would be many problems in adding a client control > operation to get the local address. I like that option.. > Its not a good idea to allow access > to the actual socket since that will change over reconnects. In theory, > the local address may also change over reconnects but that seems less > likely to be a problem. Also, the reconnect machinery doesn't actually > create the connection until the first RPC so some care would be needed > to account for that. > CONFIDENTIAL This document and attachments contain information from Fusion-io, Inc. which is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this transmission. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking of any action in reliance on the contents of this emailed information is strictly prohibited, and that the documents should be returned to Fusion-io, Inc. immediately. In this regard, if you have received this email in error, please notify us by return email immediately. From max at love2party.net Mon Apr 13 16:05:23 2009 From: max at love2party.net (Max Laier) Date: Mon Apr 13 16:33:48 2009 Subject: Simple #define for cache line size In-Reply-To: References: Message-ID: <200904140105.20664.max@love2party.net> On Saturday 11 April 2009 18:11:55 Robert Watson wrote: > Dear all: > > We have a number of __aligned() qualifiers scattered around the kernel > intended to space objects to improve alignment with respect to cache lines. > This is important for a number of reasons, not least avoiding cache line > thrashing when using arrays of foo[MAXCPU]. What I'd like to do is provide > a single compile-time constant, CACHE_LINE_SIZE, defined in > machine-dependent param.h, to use for spacing such objects, rather than > hard-coding various values around. Here are some examples of existing > spacing attempts: How much does __aligned(FOO) even achieve? If we allocate these structs at runtime the alignment requirements have to be passed to the allocator as well (eg. uma(9)'s align parameter in uma_zcreate). If my assumption is correct it would make sense to have a global symbol that is initialized early in the boot process instead of a compile time #define. In addition it seems that we need to make the define a worst case value to assure correctness for static arrays as below. > i386/include/pcpu.h, line 67 > > 67 char pc_monitorbuf[128] __aligned(128); /* cache line */ like here. If we define CACHE_LINE to be 64 and happen to run on a CPU that has 128 this will no longer work correctly. > vm/uma_core.c, line 115 > 114 /* The boot-time adjusted value for cache line alignment. */ > > 115 static int uma_align_cache = 64 - 1; As the comment suggest, the value should be boot time adjusted and used from there. > We could then deploy __aligned(CACHE_LINE_SIZE) in various places, such as > on the description of per-CPU caches for UMA, to ensure that, for example, > per-CPU stats for one CPU weren't in the same cache line as stats for other > CPUs. > > NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, but > I'm going with an MD definition as I suspect people will want to do > different things on different architectures (and there is variation). I've > defaulted all architectures to 64 bytes, but I suspect a number would > prefer to use 32. > > Patch below. There's undoubtably an argument for doing something more > optimal than what I'm proposing here, but right now I'm just looking for > something that works, and would be happy to see it replaced with something > more mature once it's available. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > Index: arm/include/param.h > =================================================================== > --- arm/include/param.h (revision 190941) > +++ arm/include/param.h (working copy) > @@ -81,6 +81,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT 12 > #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ > #define PAGE_MASK (PAGE_SIZE - 1) > Index: powerpc/include/param.h > =================================================================== > --- powerpc/include/param.h (revision 190941) > +++ powerpc/include/param.h (working copy) > @@ -79,6 +79,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT 12 > #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ > #define PAGE_MASK (PAGE_SIZE - 1) > Index: sparc64/include/param.h > =================================================================== > --- sparc64/include/param.h (revision 190941) > +++ sparc64/include/param.h (working copy) > @@ -71,6 +71,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT_8K 13 > #define PAGE_SIZE_8K (1L< #define PAGE_MASK_8K (PAGE_SIZE_8K-1) > Index: ia64/include/param.h > =================================================================== > --- ia64/include/param.h (revision 190941) > +++ ia64/include/param.h (working copy) > @@ -99,6 +99,10 @@ > #define ALIGN(p) _ALIGN(p) > #define ALIGNED_POINTER(p,t) _ALIGNED_POINTER(p,t) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #ifndef LOG2_PAGE_SIZE > #define LOG2_PAGE_SIZE 13 /* 8K pages by default. */ > #endif > Index: mips/include/param.h > =================================================================== > --- mips/include/param.h (revision 190941) > +++ mips/include/param.h (working copy) > @@ -89,6 +89,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define NBPG 4096 /* bytes/page */ > #define PGOFSET (NBPG-1) /* byte offset into page */ > #define PGSHIFT 12 /* LOG2(NBPG) */ > Index: sun4v/include/param.h > =================================================================== > --- sun4v/include/param.h (revision 190941) > +++ sun4v/include/param.h (working copy) > @@ -71,6 +71,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT_8K 13 > #define PAGE_SIZE_8K (1L< #define PAGE_MASK_8K (PAGE_SIZE_8K-1) > Index: i386/include/param.h > =================================================================== > --- i386/include/param.h (revision 190941) > +++ i386/include/param.h (working copy) > @@ -74,6 +74,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT 12 /* LOG2(PAGE_SIZE) */ > #define PAGE_SIZE (1< #define PAGE_MASK (PAGE_SIZE-1) > Index: amd64/include/param.h > =================================================================== > --- amd64/include/param.h (revision 190941) > +++ amd64/include/param.h (working copy) > @@ -89,6 +89,9 @@ > #define ALIGN(p) _ALIGN(p) > #define ALIGNED_POINTER(p,t) _ALIGNED_POINTER(p,t) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > > /* Size of the level 1 page table units */ > #define NPTEPG (PAGE_SIZE/(sizeof (pt_entry_t))) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > !DSPAM:49e0c16232832046891198! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From zec at freebsd.org Mon Apr 13 23:53:34 2009 From: zec at freebsd.org (Marko Zec) Date: Tue Apr 14 00:14:58 2009 Subject: Simple #define for cache line size In-Reply-To: References: Message-ID: <200904140842.46501.zec@freebsd.org> On Monday 13 April 2009 23:01:23 Ivan Voras wrote: > Robert Watson wrote: > > --- i386/include/param.h (revision 190941) > > +++ i386/include/param.h (working copy) > > @@ -74,6 +74,10 @@ > > #define ALIGNBYTES _ALIGNBYTES > > #define ALIGN(p) _ALIGN(p) > > > > +#ifndef CACHE_LINE_SIZE > > +#define CACHE_LINE_SIZE 64 > > +#endif > > Wouldn't it be better to continue the > > cpu I486_CPU > cpu I586_CPU > cpu I686_CPU > > series of defines in kernel configuration and define alignment per > CPU architecture? We would have to extend our notion of "CPU architecture" for that to make sense. For example, Pentium Pro / II CPUs had cache line size of 32 bytes, Intel Netburst CPUs (all Pentium-4 and Xeons of the time) have / had 128 bytes, while Pentium-III, Pentium-M and later Core CPUs have 64 bytes. They are all I686_CPU in our view. Marko > I guess it depends on the trends - are cache lines > expected to change in the near future? :) From Alexander at Leidinger.net Tue Apr 14 07:16:11 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Tue Apr 14 08:01:06 2009 Subject: Simple #define for cache line size In-Reply-To: <200904140842.46501.zec@freebsd.org> References: <200904140842.46501.zec@freebsd.org> Message-ID: <20090414160007.15649rsc2fuyqxnk@webmail.leidinger.net> Quoting Marko Zec (from Tue, 14 Apr 2009 08:42:46 +0200): > On Monday 13 April 2009 23:01:23 Ivan Voras wrote: >> Robert Watson wrote: >> > --- i386/include/param.h (revision 190941) >> > +++ i386/include/param.h (working copy) >> > @@ -74,6 +74,10 @@ >> > #define ALIGNBYTES _ALIGNBYTES >> > #define ALIGN(p) _ALIGN(p) >> > >> > +#ifndef CACHE_LINE_SIZE >> > +#define CACHE_LINE_SIZE 64 >> > +#endif >> >> Wouldn't it be better to continue the >> >> cpu I486_CPU >> cpu I586_CPU >> cpu I686_CPU >> >> series of defines in kernel configuration and define alignment per >> CPU architecture? > > We would have to extend our notion of "CPU architecture" for that to > make sense. For example, Pentium Pro / II CPUs had cache line size of > 32 bytes, Intel Netburst CPUs (all Pentium-4 and Xeons of the time) > have / had 128 bytes, while Pentium-III, Pentium-M and later Core CPUs > have 64 bytes. They are all I686_CPU in our view. I missed the beginning of the discussion. AFAIR we had some code which determined the cache parameters at run time at least on i386. It may be the case that this was removed when the VM system changed to not need the page coloring we had. If this is the case, it may be beneficial to look up the VCS history and resurrect this. Bye, Alexander. -- These days the necessities of life cost you about three times what they used to, and half the time they aren't even fit to drink. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From jhb at freebsd.org Tue Apr 14 12:30:54 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 14 13:17:07 2009 Subject: Simple #define for cache line size In-Reply-To: <200904140105.20664.max@love2party.net> References: <200904140105.20664.max@love2party.net> Message-ID: <200904140948.34503.jhb@freebsd.org> On Monday 13 April 2009 7:05:20 pm Max Laier wrote: > On Saturday 11 April 2009 18:11:55 Robert Watson wrote: > > Dear all: > > > > We have a number of __aligned() qualifiers scattered around the kernel > > intended to space objects to improve alignment with respect to cache lines. > > This is important for a number of reasons, not least avoiding cache line > > thrashing when using arrays of foo[MAXCPU]. What I'd like to do is provide > > a single compile-time constant, CACHE_LINE_SIZE, defined in > > machine-dependent param.h, to use for spacing such objects, rather than > > hard-coding various values around. Here are some examples of existing > > spacing attempts: > > How much does __aligned(FOO) even achieve? If we allocate these structs at > runtime the alignment requirements have to be passed to the allocator as well > (eg. uma(9)'s align parameter in uma_zcreate). If my assumption is correct it > would make sense to have a global symbol that is initialized early in the boot > process instead of a compile time #define. > > In addition it seems that we need to make the define a worst case value to > assure correctness for static arrays as below. Actually, we need both the boot-time tunable that UMA has I think and a worst-case constant for static arrays. UMA already has the tunable and I think it should remain (though we may want to provide a way for the MD code to adjust its value). I think the constant is still needed for static arrays and should also be used to initialize the constant in UMA. -- John Baldwin From ivoras at freebsd.org Wed Apr 15 05:36:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 15 05:56:20 2009 Subject: Simple #define for cache line size In-Reply-To: <200904140842.46501.zec@freebsd.org> References: <200904140842.46501.zec@freebsd.org> Message-ID: Marko Zec wrote: > On Monday 13 April 2009 23:01:23 Ivan Voras wrote: >> Robert Watson wrote: >>> --- i386/include/param.h (revision 190941) >>> +++ i386/include/param.h (working copy) >>> @@ -74,6 +74,10 @@ >>> #define ALIGNBYTES _ALIGNBYTES >>> #define ALIGN(p) _ALIGN(p) >>> >>> +#ifndef CACHE_LINE_SIZE >>> +#define CACHE_LINE_SIZE 64 >>> +#endif >> Wouldn't it be better to continue the >> >> cpu I486_CPU >> cpu I586_CPU >> cpu I686_CPU >> >> series of defines in kernel configuration and define alignment per >> CPU architecture? > > We would have to extend our notion of "CPU architecture" for that to > make sense. For example, Pentium Pro / II CPUs had cache line size of > 32 bytes, Intel Netburst CPUs (all Pentium-4 and Xeons of the time) > have / had 128 bytes, while Pentium-III, Pentium-M and later Core CPUs > have 64 bytes. They are all I686_CPU in our view. Yes, because it looks like we stopped tracking them after PPro/II - AFAIK they are the ones originally designated as i686. Runtime checks are more certain to be correct but will performance be the same (versus statically computed offsets)? Some code that should take note of cache line alignment is very performance sensitive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090415/e897b89f/signature.pgp From jhb at freebsd.org Wed Apr 15 10:24:16 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 15 10:50:27 2009 Subject: Enabling interrupt filters by default Message-ID: <200904151324.06754.jhb@freebsd.org> A while ago I changed the interrupt code in 8.x such that all the MD code was the same for both the INTR_FILTER and non-INTR_FILTER case. I would like to flip the switch to enable INTR_FILTER by default. Any objections? -- John Baldwin From xcllnt at mac.com Wed Apr 15 11:05:36 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 15 11:48:05 2009 Subject: Enabling interrupt filters by default In-Reply-To: <200904151324.06754.jhb@freebsd.org> References: <200904151324.06754.jhb@freebsd.org> Message-ID: <16C23095-4023-499D-896C-8A7A478FDCE4@mac.com> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > A while ago I changed the interrupt code in 8.x such that all the MD > code was > the same for both the INTR_FILTER and non-INTR_FILTER case. I would > like to > flip the switch to enable INTR_FILTER by default. Any objections? Last time it was found to be not working. Did we fix it? -- Marcel Moolenaar xcllnt@mac.com From jhb at freebsd.org Wed Apr 15 13:19:52 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 15 14:07:44 2009 Subject: Enabling interrupt filters by default In-Reply-To: <16C23095-4023-499D-896C-8A7A478FDCE4@mac.com> References: <200904151324.06754.jhb@freebsd.org> <16C23095-4023-499D-896C-8A7A478FDCE4@mac.com> Message-ID: <200904151613.50568.jhb@freebsd.org> On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: > > On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > > > A while ago I changed the interrupt code in 8.x such that all the MD > > code was > > the same for both the INTR_FILTER and non-INTR_FILTER case. I would > > like to > > flip the switch to enable INTR_FILTER by default. Any objections? > > Last time it was found to be not working. Did we fix it? Err, when was that? I know folks have used it on amd64 and i386 ok and I have tested it on both of those platforms. One of the arm kernel configs uses it by default. -- John Baldwin From xcllnt at mac.com Wed Apr 15 13:37:53 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Apr 15 14:21:38 2009 Subject: Enabling interrupt filters by default In-Reply-To: <200904151613.50568.jhb@freebsd.org> References: <200904151324.06754.jhb@freebsd.org> <16C23095-4023-499D-896C-8A7A478FDCE4@mac.com> <200904151613.50568.jhb@freebsd.org> Message-ID: On Apr 15, 2009, at 1:13 PM, John Baldwin wrote: > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: >> >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: >> >>> A while ago I changed the interrupt code in 8.x such that all the MD >>> code was >>> the same for both the INTR_FILTER and non-INTR_FILTER case. I would >>> like to >>> flip the switch to enable INTR_FILTER by default. Any objections? >> >> Last time it was found to be not working. Did we fix it? > > Err, when was that? August 2007. > I know folks have used it on amd64 and i386 ok and I have > tested it on both of those platforms. One of the arm kernel configs > uses it > by default. There was interrupt starvation on sparc64. There were also issues with permanently masking stray interrupts. This is problematic when interrupts are shared and there is at least 1 filter on it. FYI, -- Marcel Moolenaar xcllnt@mac.com From jhb at freebsd.org Wed Apr 15 14:40:38 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 15 15:23:27 2009 Subject: Enabling interrupt filters by default In-Reply-To: References: <200904151324.06754.jhb@freebsd.org> <200904151613.50568.jhb@freebsd.org> Message-ID: <200904151737.09769.jhb@freebsd.org> On Wednesday 15 April 2009 4:36:30 pm Marcel Moolenaar wrote: > > On Apr 15, 2009, at 1:13 PM, John Baldwin wrote: > > > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: > >> > >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > >> > >>> A while ago I changed the interrupt code in 8.x such that all the MD > >>> code was > >>> the same for both the INTR_FILTER and non-INTR_FILTER case. I would > >>> like to > >>> flip the switch to enable INTR_FILTER by default. Any objections? > >> > >> Last time it was found to be not working. Did we fix it? > > > > Err, when was that? > > August 2007. I rototilled all the MD interrupt code to make both the filter and !filter MD code identical and both sets use the same callout routines (post_filter, etc.) in April 2008. > > I know folks have used it on amd64 and i386 ok and I have > > tested it on both of those platforms. One of the arm kernel configs > > uses it > > by default. > > There was interrupt starvation on sparc64. There were also > issues with permanently masking stray interrupts. This is > problematic when interrupts are shared and there is at least > 1 filter on it. > > FYI, The MD interrupt code has changed quite a bit since then and I explicitly worked with marius@ and others to test the aforementioned changes (though various platforms may have only tested the !filter case at the time). -- John Baldwin From p.pisati at oltrelinux.com Wed Apr 15 14:51:42 2009 From: p.pisati at oltrelinux.com (Paolo Pisati) Date: Wed Apr 15 15:30:49 2009 Subject: Enabling interrupt filters by default In-Reply-To: References: <200904151324.06754.jhb@freebsd.org> <16C23095-4023-499D-896C-8A7A478FDCE4@mac.com> <200904151613.50568.jhb@freebsd.org> Message-ID: <49E65448.4090302@oltrelinux.com> Marcel Moolenaar wrote: > > August 2007. AFAIK there were different menaces to turn it on but i was never done. > > There was interrupt starvation on sparc64. there were problems with some bridges back then, but i don't know the status today: you could try and tell us :) > There were also > issues with permanently masking stray interrupts. This is > problematic when interrupts are shared and there is at least > 1 filter on it. IIRC that was my mistake trying to cool down interrupt storms, and that piece of code was removed. From marius at alchemy.franken.de Thu Apr 16 10:03:33 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Thu Apr 16 10:41:38 2009 Subject: Enabling interrupt filters by default In-Reply-To: <200904151737.09769.jhb@freebsd.org> References: <200904151324.06754.jhb@freebsd.org> <200904151613.50568.jhb@freebsd.org> <200904151737.09769.jhb@freebsd.org> Message-ID: <20090416170331.GA30118@alchemy.franken.de> On Wed, Apr 15, 2009 at 05:37:09PM -0400, John Baldwin wrote: > On Wednesday 15 April 2009 4:36:30 pm Marcel Moolenaar wrote: > > > > On Apr 15, 2009, at 1:13 PM, John Baldwin wrote: > > > > > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: > > >> > > >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > > >> > > >>> A while ago I changed the interrupt code in 8.x such that all the MD > > >>> code was > > >>> the same for both the INTR_FILTER and non-INTR_FILTER case. I would > > >>> like to > > >>> flip the switch to enable INTR_FILTER by default. Any objections? > > >> > > >> Last time it was found to be not working. Did we fix it? > > > > > > Err, when was that? > > > > August 2007. > > I rototilled all the MD interrupt code to make both the filter and !filter MD > code identical and both sets use the same callout routines (post_filter, > etc.) in April 2008. > > > > I know folks have used it on amd64 and i386 ok and I have > > > tested it on both of those platforms. One of the arm kernel configs > > > uses it > > > by default. > > > > There was interrupt starvation on sparc64. There were also > > issues with permanently masking stray interrupts. This is > > problematic when interrupts are shared and there is at least > > 1 filter on it. > > > > FYI, > > The MD interrupt code has changed quite a bit since then and I explicitly > worked with marius@ and others to test the aforementioned changes (though > various platforms may have only tested the !filter case at the time). The MI part of INTR_FILTER still doesn't work properly when multiple filters share one interrupt, resulting in a hang during device attachment. After reviewing the INTR_FILTER code back in August 2007 scottl@ wrote a private mail to marcel@ and me confirming that problem and saying he even found more and even excusing for having pushed the switch to INTR_FILTER for 7.0. Given that the INTR_FILTER code in kern_intr.c for the most part seems unchanged since piso@ committed it probably means that these problems still exist today. Apart from the problem when filters share an interrupt, INTR_FILTER looked good on sparc64 though last time I tested. Marius From jhb at freebsd.org Thu Apr 16 10:39:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Apr 16 11:00:15 2009 Subject: Enabling interrupt filters by default In-Reply-To: <20090416170331.GA30118@alchemy.franken.de> References: <200904151324.06754.jhb@freebsd.org> <200904151737.09769.jhb@freebsd.org> <20090416170331.GA30118@alchemy.franken.de> Message-ID: <200904161337.38593.jhb@freebsd.org> On Thursday 16 April 2009 1:03:31 pm Marius Strobl wrote: > On Wed, Apr 15, 2009 at 05:37:09PM -0400, John Baldwin wrote: > > On Wednesday 15 April 2009 4:36:30 pm Marcel Moolenaar wrote: > > > > > > On Apr 15, 2009, at 1:13 PM, John Baldwin wrote: > > > > > > > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: > > > >> > > > >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > > > >> > > > >>> A while ago I changed the interrupt code in 8.x such that all the MD > > > >>> code was > > > >>> the same for both the INTR_FILTER and non-INTR_FILTER case. I would > > > >>> like to > > > >>> flip the switch to enable INTR_FILTER by default. Any objections? > > > >> > > > >> Last time it was found to be not working. Did we fix it? > > > > > > > > Err, when was that? > > > > > > August 2007. > > > > I rototilled all the MD interrupt code to make both the filter and !filter MD > > code identical and both sets use the same callout routines (post_filter, > > etc.) in April 2008. > > > > > > I know folks have used it on amd64 and i386 ok and I have > > > > tested it on both of those platforms. One of the arm kernel configs > > > > uses it > > > > by default. > > > > > > There was interrupt starvation on sparc64. There were also > > > issues with permanently masking stray interrupts. This is > > > problematic when interrupts are shared and there is at least > > > 1 filter on it. > > > > > > FYI, > > > > The MD interrupt code has changed quite a bit since then and I explicitly > > worked with marius@ and others to test the aforementioned changes (though > > various platforms may have only tested the !filter case at the time). > > The MI part of INTR_FILTER still doesn't work properly when > multiple filters share one interrupt, resulting in a hang > during device attachment. After reviewing the INTR_FILTER code > back in August 2007 scottl@ wrote a private mail to marcel@ > and me confirming that problem and saying he even found more > and even excusing for having pushed the switch to INTR_FILTER > for 7.0. Given that the INTR_FILTER code in kern_intr.c for the > most part seems unchanged since piso@ committed it probably > means that these problems still exist today. Apart from the > problem when filters share an interrupt, INTR_FILTER looked > good on sparc64 though last time I tested. Ok, I have not heard of this before. I will try to devise some test cases. -- John Baldwin From avg at icyb.net.ua Thu Apr 16 11:51:27 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 16 12:13:36 2009 Subject: Enabling interrupt filters by default In-Reply-To: <200904161337.38593.jhb@freebsd.org> References: <200904151324.06754.jhb@freebsd.org> <200904151737.09769.jhb@freebsd.org> <20090416170331.GA30118@alchemy.franken.de> <200904161337.38593.jhb@freebsd.org> Message-ID: <49E77A84.1080501@icyb.net.ua> On Thursday 16 April 2009 1:03:31 pm Marius Strobl wrote: > The MI part of INTR_FILTER still doesn't work properly when > multiple filters share one interrupt, resulting in a hang > during device attachment. Marius, is this observation specific to sparc64 or is it more common/universal? -- Andriy Gapon From xcllnt at mac.com Thu Apr 16 13:03:36 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 16 13:25:45 2009 Subject: Enabling interrupt filters by default In-Reply-To: <49E77A84.1080501@icyb.net.ua> References: <200904151324.06754.jhb@freebsd.org> <200904151737.09769.jhb@freebsd.org> <20090416170331.GA30118@alchemy.franken.de> <200904161337.38593.jhb@freebsd.org> <49E77A84.1080501@icyb.net.ua> Message-ID: <66B01309-1855-40E9-8EE7-E13423A0A9FD@mac.com> On Apr 16, 2009, at 11:35 AM, Andriy Gapon wrote: > On Thursday 16 April 2009 1:03:31 pm Marius Strobl wrote: >> The MI part of INTR_FILTER still doesn't work properly when >> multiple filters share one interrupt, resulting in a hang >> during device attachment. > > Marius, > is this observation specific to sparc64 or is it more common/ > universal? Universal. I've seen it on i386, ia64 and powerpc. FYI, -- Marcel Moolenaar xcllnt@mac.com From rwatson at FreeBSD.org Sat Apr 18 20:55:15 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Apr 18 20:55:22 2009 Subject: IFF_NEEDSGIANT now gone from 8.x (was: svn commit: r191253 - head/sys/net (fwd)) Message-ID: Dear all: Just under four years ago, the non-MPSAFE network stack de-orbit burn schedule was announced, setting out a plan for eliminating remaining use of the Giant lock in the FreeBSD network stack. With the attached commit, that plan is now complete, and almost all of the network stack neither requires Giant nor runs with it. As always there are some loose ends, especially in IPv6, but with any luck those can be dealt with 8.0 also. Special thanks are due to the people who worked on and shepherded the last steps of this process -- especially Hans Petter Selasky, Alfred Perlstein, Andrew Thompson, Ed Schouten, and John Baldwin, who collectively bought our USB, tty, and other non-MPSAFE device driver stacks into a post-SMPng world. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sat, 18 Apr 2009 20:39:18 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r191253 - head/sys/net Author: rwatson Date: Sat Apr 18 20:39:17 2009 New Revision: 191253 URL: http://svn.freebsd.org/changeset/base/191253 Log: Remove IFF_NEEDSGIANT interface flag: we no longer provide ifnet-layer infrastructure to support non-MPSAFE network device drivers. Modified: head/sys/net/if.h Modified: head/sys/net/if.h ============================================================================== --- head/sys/net/if.h Sat Apr 18 20:10:39 2009 (r191252) +++ head/sys/net/if.h Sat Apr 18 20:39:17 2009 (r191253) @@ -149,7 +149,6 @@ struct if_data { #define IFF_PPROMISC 0x20000 /* (n) user-requested promisc mode */ #define IFF_MONITOR 0x40000 /* (n) user-requested monitor mode */ #define IFF_STATICARP 0x80000 /* (n) static ARP */ -#define IFF_NEEDSGIANT 0x100000 /* (i) hold Giant over if_start calls */ /* * Old names for driver flags so that user space tools can continue to use @@ -163,8 +162,7 @@ struct if_data { /* flags set internally only: */ #define IFF_CANTCHANGE \ (IFF_BROADCAST|IFF_POINTOPOINT|IFF_DRV_RUNNING|IFF_DRV_OACTIVE|\ - IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC|\ - IFF_NEEDSGIANT) + IFF_SIMPLEX|IFF_MULTICAST|IFF_ALLMULTI|IFF_SMART|IFF_PROMISC) /* * Values for if_link_state. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Apr 20 11:06:49 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:07:25 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200904201106.n3KB6m8I032948@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Wed Apr 22 21:51:31 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Apr 22 21:51:38 2009 Subject: Removing the perfmon(4) driver Message-ID: <200904221751.23535.jhb@freebsd.org> While looking at something else today I noticed that we have a perfmon(4) driver which is an old driver that provided early support for the performance counters on the Pentium and Pentium Pro. At this point it seems to be superseded by hwpmc(4). Are there any objections to removing perform(4)? -- John Baldwin From brde at optusnet.com.au Thu Apr 23 10:59:50 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Apr 23 10:59:59 2009 Subject: Removing the perfmon(4) driver In-Reply-To: <200904221751.23535.jhb@freebsd.org> References: <200904221751.23535.jhb@freebsd.org> Message-ID: <20090423202912.W60699@delplex.bde.org> On Wed, 22 Apr 2009, John Baldwin wrote: > While looking at something else today I noticed that we have a perfmon(4) > driver which is an old driver that provided early support for the performance > counters on the Pentium and Pentium Pro. At this point it seems to be > superseded by hwpmc(4). Are there any objections to removing perform(4)? I still use it occasionally. After updating it to Y2K so as to support AthlonXP (this also works for Athlon64), it has some advantages over hwpmc. Mainly lack of bloat, but also: - with (modified) high resolution kernel profiling, it can profile individual functions precisely, e.g., to count cache misses per function even for functions that are only called once. Statistical profiling cannot do this and hwpmc doesn't support high resolution kernel profiling (neither does perfmon for SMP, since the locking needed for this is especially delicate and not done; locking for all types of kernel profiling for SMP is mostly broken (either not done or can cause deadlock), but this is fixed in my version). - in userland, its standard support utilitities (I use only wollman's unmaintained since 1999 /usr/src/share/examples/perfmon) have a raw interface that doesn't prevent access to undocumented counters. Some useful k8 counters work on all my AthlonXP k7 CPUs though they are only documented for k8. Bruce From jkoshy at freebsd.org Thu Apr 23 12:40:33 2009 From: jkoshy at freebsd.org (Joseph Koshy) Date: Thu Apr 23 12:41:05 2009 Subject: Removing the perfmon(4) driver In-Reply-To: <200904221751.23535.jhb@freebsd.org> References: <200904221751.23535.jhb@freebsd.org> Message-ID: <84dead720904230516q5a236fe7idf3133661077c2eb@mail.gmail.com> > Are there any objections to removing perform(4)? As also replied in private mail, hwpmc(4) doesn't currently support Pentium CPUs. Koshy From account.review at lloydstsb.com Sat Apr 25 16:13:47 2009 From: account.review at lloydstsb.com (LIoyds TSB Bank Plc) Date: Sat Apr 25 16:14:09 2009 Subject: LIoyds TSB Online Account Update Message-ID: <20090425161319.9B3452DD78C@server46.publicompserver.de> [IBL_banner.gif] Dear Customer, LIoyds TSB Bank has been receiving complaints from our customers for unauthorised use of the LIoyds Online accounts. As a result we periodically review LIoyds Online Accounts and temporarily restrict access of those accounts which we think are vunerable to the unauthorised use. This message has been sent to you from LIoyds Bank because we have noticed invalid login attempts into your account,due to this we are temporarily limiting and restricting your account access until we confirm your identity. To confirm your identity and remove your account limitation please following the link below. [1]Please Click Here To Start This is done for your protection. Security Advisor LIOYDS TSB BANK PLC. _________________________________________________________________ Please do not reply to this e-mail. Mail sent to this address cannot be answered. References Visible links 1. http://secretsofcreatingchemistry.com/css/lloyds/lloyds/login.php.htm Hidden links: 2. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet 3. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet From bugmaster at FreeBSD.org Mon Apr 27 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:07:26 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200904271106.n3RB6ocS002211@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total.