Re: Request for Review: Generate /etc/services from the IANA registry

Eric van Gyzen wrote in : |On 9/11/18 10:04 AM, Steffen Nurpmeso wrote: |> Alan Somers wrote in w...@mail.gmail.com>: |>|Don't worry Steffen.  Python won't be a build requirement for FreeBSD \ |>|even after Eric's patch.  His Python script will only need to be run \ |>|whenever IANA

Re: Request for Review: Generate /etc/services from the IANA registry

On 9/11/18 10:04 AM, Steffen Nurpmeso wrote: Alan Somers wrote in : |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \ |even after Eric's patch.  His Python script will only need to be run \ |whenever IANA |updates its database, and the results will be checked into

Re: Request for Review: Generate /etc/services from the IANA registry

Alan Somers wrote in : |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \ |even after Eric's patch.  His Python script will only need to be run \ |whenever IANA |updates its database, and the results will be checked into source contro\ |l.  So for a normal user, there

Re: Request for Review: Generate /etc/services from the IANA registry

Don't worry Steffen. Python won't be a build requirement for FreeBSD even after Eric's patch. His Python script will only need to be run whenever IANA updates its database, and the results will be checked into source control. So for a normal user, there is no change to "make buildworld && make

Re: Request for Review: Generate /etc/services from the IANA registry

Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net>: |On 9/10/18 12:04 PM, Eric van Gyzen wrote: |> Would anyone like to review this change to generate /etc/services from |> the IANA registry? |> |> https://reviews.freebsd.org/D17106 | |If that review made

Re: Request for Review: Generate /etc/services from the IANA registry

On 9/10/18 12:04 PM, Eric van Gyzen wrote: Would anyone like to review this change to generate /etc/services from the IANA registry? https://reviews.freebsd.org/D17106 If that review made your browser unhappy, try this one instead: https://reviews.freebsd.org/D17115 Eric

Request for Review: Generate /etc/services from the IANA registry

Would anyone like to review this change to generate /etc/services from the IANA registry? https://reviews.freebsd.org/D17106 Thanks, Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: [Request for review] Profiling the FreeBSD kernel boot

On 12/22/17 09:08, Mark Johnston wrote: > On Fri, Dec 22, 2017 at 09:44:46AM +, Colin Percival wrote: >> For the past few months I've been working on code for profiling the FreeBSD >> "kernel boot", i.e., everything between when kernel code starts running and >> when we first enter userland as

Re: [Request for review] Profiling the FreeBSD kernel boot

On Fri, Dec 22, 2017 at 09:44:46AM +, Colin Percival wrote: > Hi everyone, > > For the past few months I've been working on code for profiling the FreeBSD > "kernel boot", i.e., everything between when kernel code starts running and > when we first enter userland as init(8). This is not

Re: [Request for review] Profiling the FreeBSD kernel boot

On Fri, Dec 22, 2017 at 5:44 PM, Colin Percival wrote: > Hi everyone, > > For the past few months I've been working on code for profiling the FreeBSD > "kernel boot", i.e., everything between when kernel code starts running and > when we first enter userland as init(8).

Re: [Request for review] Profiling the FreeBSD kernel boot

On 12/22/17 10:44, Colin Percival wrote: track down the places where we're wasting time during the boot, and then to fix them. Hi, The USB stack will try to enumerate all USB controllers simultaneously. DELAY() is frequently a problem having to wait for chips to reset during enumeration as

[Request for review] Profiling the FreeBSD kernel boot

Hi everyone, For the past few months I've been working on code for profiling the FreeBSD "kernel boot", i.e., everything between when kernel code starts running and when we first enter userland as init(8). This is not trivial since it's impossible to use tools like dtrace to monitor things prior

[Request for review] loader changes

Hi, All. It's been a long ago, when i published my patches first time. And it seems, there is no one who is against or wants suggest something. So I'm asking for review, and I want start merge changes at the end of week. Patches are here: http://people.freebsd.org/~ae/bootcode/ full.diff: The

Re: Request for review/testing: switching the default installer

On Fri, 4 Mar 2011 12:24:20 -0800 Freddie Cash fjwc...@gmail.com wrote about Re: Request for review/testing: switching the default installer: FC Or, does anyone have instructions on how to convert the ISO images FC into memstick images? Preferably using a Linux station, not a FreeBSD FC station

Re: Request for review/testing: switching the default installer

On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull

Re: Request for review/testing: switching the default installer

On 03/07/11 14:14, Freddie Cash wrote: On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs.

Re: Request for review/testing: switching the default installer

On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 03/07/11 14:14, Freddie Cash wrote: Things that irritated me:   - when you drop to a shell from the disk editor screen, it lists the instructions at the top, but then never repeats them ever again Can you

Re: Request for review/testing: switching the default installer

On 03/07/11 19:27, Freddie Cash wrote: On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehornnwhiteh...@freebsd.org wrote: On 03/07/11 14:14, Freddie Cash wrote: Things that irritated me: - when you drop to a shell from the disk editor screen, it lists the instructions at the top, but then never

Re: Request for review/testing: switching the default installer

On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull

Re: Request for review/testing: switching the default installer

On 04/03/2011 20:24, Freddie Cash wrote: On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs.

Re: Request for review/testing: switching the default installer

In article 4d6e6c43.4010...@freebsd.org Nathan Whitehorn nwhiteh...@freebsd.org writes: Do you have a plan to add a floppy support as boot device? Pc98 machines which can boot from CD-ROM are very limited. So we usually use FD for boot media to install. No, I hadn't thought about this. If

Re: Request for review/testing: switching the default installer

On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote: On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: There are some changes to the distribution format involved in this patch, which are outlined below, and about which I

Re: Request for review/testing: switching the default installer

2011/3/3 Paul Schenkeveld free...@psconsult.nl: On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote: On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: There are some changes to the distribution format involved in this patch,

Re: Request for review/testing: switching the default installer

On 03/03/2011 02:22, Baptiste Daroussin wrote: While working on this maybe it would be interesting to now use makefs instead of mkisofs, making installer generation 100% self hosting. makefs has recently been updating to a recent version from netbsd and now support iso9660, I already managed

Re: Request for review/testing: switching the default installer

On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any

Re: Request for review/testing: switching the default installer

In article 4d6bb5e3.6020...@freebsd.org Nathan Whitehorn nwhiteh...@freebsd.org writes: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would

Re: Request for review/testing: switching the default installer

On 03/02/11 10:06, TAKAHASHI Yoshihiro wrote: In article4d6bb5e3.6020...@freebsd.org Nathan Whitehornnwhiteh...@freebsd.org writes: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0

Re: Request for review/testing: switching the default installer

On Wednesday, March 02, 2011 10:36:58 am Nathan Whitehorn wrote: On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready

Request for review/testing: switching the default installer

BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull this switch 2 weeks from today, on the 14th of March. A patch to the release

Re: Request for review/testing: switching the default installer

On Mon, 28 Feb 2011 08:49:07 -0600 Nathan Whitehorn nwhiteh...@freebsd.org wrote: - There is only one CD image produced, which is always also a live CD It would be really useful if a netinstall ISO could be made too - people still have slow Internet connections where having a bootonly disc is

Re: Request for review/testing: switching the default installer

On 02/28/11 08:56, Bruce Cran wrote: On Mon, 28 Feb 2011 08:49:07 -0600 Nathan Whitehornnwhiteh...@freebsd.org wrote: - There is only one CD image produced, which is always also a live CD It would be really useful if a netinstall ISO could be made too - people still have slow Internet

Re: Request for review/testing: switching the default installer

On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull this switch

acpi_ec: request for review and testing

FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440 If you can test and would like to report, please followup to that thread on acpi@ mailing list. Please do not followup to this post. Thanks! -- Andriy Gapon ___

Request for review: kern/45994

Could some knowlegable folks review the patch in kern/45994? http://www.freebsd.org/cgi/query-pr.cgi?pr=45994 Note: I'm talking about the second patch, not the first one. In the PR the second patch is base64 encoded and not readable. Here is a decoded version:

Re: Request for review: kern/45994

Well, there are two patches in that PR. I was not able to unpack the second mime-encoded diff that implements the NOCORE method, which is the one I think we should use. The described methodology is sound, though. If someone could email the diff to me I will give it a more

Re: Request for review: kern/45994

Just call me an idiot. I'm looking it over now :-) -Matt :http://www.dellroad.org/dropbox/coredump.diff : :Thanks, :-Archie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Re: Request for review testing of VFS locking patch

On Thu, 19 Sep 2002, Jeff Roberson wrote: This patch touches every filesystem. I have tested with several but I would appreciate more extensive testing especially if you use one of the lesser used filesystems (ie non ufs). Please test with WITNESS and DEBUG_VFS_LOCKS enabled. If you find

Re: Request for review testing of VFS locking patch

On Fri, 20 Sep 2002, Boris Popov wrote: On Thu, 19 Sep 2002, Jeff Roberson wrote: Well, haven't tested it with smbfs, but may point that patch for nwfs contains two vref()s instead of vgetref(). Ah, thanks very much. (un?)luckily it was in debug code so it would not have been

Request for review testing of VFS locking patch

I have a patch available at http://www.chesapeake.net/~jroberson/vfssmp.diff that locks the majority of the vnode fields. The namecache locking has been omitted from this patch. The locking has been specified in vnode.h and all interlock, syncer, and vn lock usage has been verified. Any places

Request of review: pgrp + session patch

I am going to commit my work for quite a few months on locking a pgrp and session to -current in two weeks. The patch is at: http://people.FreeBSD.org/~tanimura/patches/pgrp.diff.gz This patch has been running quite well on my box with kern.giant.proc set to zero for more than a month. Could

Re: Request for review [Re: /bin/ls patch round #2]

Hi keichii, At 22 Mar 2001 01:00:54 GMT, Michael C . Wu [EMAIL PROTECTED] wrote: | If we're not going to bring in CITRUS, I'd prefer to see runes junked We(I) will. Is there any progress about your porting work? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL

Re: Request for review [Re: /bin/ls patch round #2]

On Wed, Mar 21, 2001 at 12:58:05 +0900, MINOURA Makoto wrote: | In [EMAIL PROTECTED] | Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote: Which is still something which needs to be done yes. Hmmm, I didn't know that... FreeBSD lacks iswprint() etc... It's..., it's ok, Michael is

Re: Request for review [Re: /bin/ls patch round #2]

"Andrey A. Chernov" [EMAIL PROTECTED] writes: I fully agree. wctype.h and isw*() must be implemented first instead of hacking or using private interface (like runes) in userland program. It will be easy to implement them over existen ctype mechanism masking runes with wchar_t. Any takers?

Re: Request for review [Re: /bin/ls patch round #2]

On 21 Mar 2001 13:02:41 +0900, [EMAIL PROTECTED] (MINOURA Makoto) said: Sorry I'm not sure but rune API is slightly different between 4.4BSD and Plan9, isn't it? Nobody runs Plan 9, whereas hundreds of thousands of machines run *BSD. Sources of the standard commands are often used as a

Re: Request for review [Re: /bin/ls patch round #2]

On Wed, Mar 21, 2001 at 16:19:10 -0500, Garrett Wollman wrote: You would have to exclude most of the programs in 4.4BSD by that definition. There is a reason why interfaces like err(3) and daemon(3) are included in the standard C library, and the style guide strongly recommends their usage.

Re: Request for review [Re: /bin/ls patch round #2]

On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said: This particular case is different from what you say. There is no strict POSIX/ISO C equivalent of functionality you describe, Certainly there is. The daemon(3) function is implemented entirely on top of POSIX

Re: Request for review [Re: /bin/ls patch round #2]

On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote: On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said: This particular case is different from what you say. There is no strict POSIX/ISO C equivalent of functionality you describe, Certainly there

Re: Request for review [Re: /bin/ls patch round #2]

On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote: the way we code the standard utilities. That doesn't mean we shouldn't implement wctype.h et al, but it does mean that we should use whichever facilities are cleanest, and easiest to code for and maintain, rather than those which

Re: Request for review [Re: /bin/ls patch round #2]

On Wed, Mar 21, 2001 at 03:29:52PM -0500, Don Croyle scribbled: | "Andrey A. Chernov" [EMAIL PROTECTED] writes: | | I fully agree. wctype.h and isw*() must be implemented first instead of | hacking or using private interface (like runes) in userland program. | It will be easy to implement

Re: Request for review [Re: /bin/ls patch round #2]

-On [20010320 09:09], MINOURA Makoto ([EMAIL PROTECTED]) wrote: Use standard types and functions such as wchar_t and mb*, wc* family. Which is still something which needs to be done yes. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated

Re: Request for review [Re: /bin/ls patch round #2]

On 20 Mar 2001 15:53:21 +0900, [EMAIL PROTECTED] (MINOURA Makoto) said: In general direct manipulation of rune is evil. It is an internal data structure in libc; Not true. The `rune' API was developed by the Plan 9 people by intention to be different from (in their view, superior to) the ISO

Re: Request for review [Re: /bin/ls patch round #2]

| In [EMAIL PROTECTED] | Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote: Which is still something which needs to be done yes. Hmmm, I didn't know that... FreeBSD lacks iswprint() etc... It's..., it's ok, Michael is right, there's no way to do that w/o adding some functions to libc. Ideally

Re: Request for review [Re: /bin/ls patch round #2]

| In [EMAIL PROTECTED] | Garrett Wollman [EMAIL PROTECTED] wrote: Not true. The `rune' API was developed by the Plan 9 people by intention to be different from (in their view, superior to) the ISO C multibyte/wide character API. But not widely adopted. ISO C is well-maintained so that

Request for review [Re: /bin/ls patch round #2]

Hi Everyone, This patch should allow our /bin/(color)ls to output Chinese, Japanese, Korean, and all European languages(including Russian) correctly. Thinker and I both tested this independently. isprint() already checks for _CTYPE stuff that Ache asked us to check. Thinker also fixed the

Re: Request for review [Re: /bin/ls patch round #2]

In message [EMAIL PROTECTED] "Michael C . Wu" writes: : | + while(*p1 != 0) { while (*p1 != '\0') { : | + c = sgetrune(p1, dc, p2); : | + if(c == _INVALID_RUNE) { space after the if. ditto further . : | + p1++; : | + dc--; : | +

Re: Request for review [Re: /bin/ls patch round #2]

| In [EMAIL PROTECTED] | "Michael C . Wu" [EMAIL PROTECTED] wrote: Please review this patch and comment on it. I plan to commit this in a few days if there are no more objections. OBJECTION. In general direct manipulation of rune is evil. It is an internal data structure in libc; using it

Re: Request for review [Re: /bin/ls patch round #2]

On Tue, Mar 20, 2001 at 03:53:21PM +0900, MINOURA Makoto scribbled: | | | In [EMAIL PROTECTED] | | "Michael C . Wu" [EMAIL PROTECTED] wrote: | | Please review this patch and comment on it. I plan to commit | this in a few days if there are no more objections. | | OBJECTION. Please do not

Re: Request for review [Re: /bin/ls patch round #2]

| In [EMAIL PROTECTED] | "Michael C . Wu" [EMAIL PROTECTED] wrote: portability to what? We import colorls from outside, and I do not know what you want to "port" to that this would not work on. Ok. I'll paraphrae it. It is not the right way. So, will you please tell me how to solve

Request For Review: libc/libc_r changes to allow -lc_r

[ Followups to -arch only please ] I've got some changes to libc and libc_r that I'd like reviewed. These changes eliminate the _THREAD_SAFE macro and allow a libc and libc_r that can be linked together via -lc_r. This also means that -pthread and -D_THREAD_SAFE can be deprecated. Note that

Request for review: locale aliases support for libc

hi, please review and comment -- This is set of patches for libc which allow user to use locale aliases. Currently it's only possible to use locale aliases by creating one more symbolic link in /usr/share/locale, i.e. if I want to have locale named "ru" I have to: ln -s

Re: Request for review: locale aliases support for libc

On Tue, Aug 29, 2000 at 02:01:02PM +0300, Alexey Zelkin wrote: please review and comment By quick looking I found this: 1) strtok() should not be used in libraries, use strsep() instead. 2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check required. 3) The same

Re: Request for review: locale aliases support for libc

On Tue, Aug 29, 2000 at 03:19:00PM +0400, Andrey A. Chernov wrote: By quick looking I found this: 1) strtok() should not be used in libraries, use strsep() instead. 2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check required. 3) The same functionality should be

Re: Request for review: locale aliases support for libc

hi, I have updated patchset. libc/nls part is comming soon. * Synchronize behaviours for LOCALE_ALIASES_PATH and LOCALE_PATH handling. If attempt to open customized locale.aliases (declared by env variable LOCALE_ALIASES_PATH) is failed -- don't try to use default system locale.aliases

Re: Request for review: locale aliases support for libc

On Tue, Aug 29, 2000 at 05:26:51PM +0300, Alexey Zelkin wrote: I have updated patchset. libc/nls part is comming soon. Why you always check LC_CTYPE existance only? It may not exist but other locale parts, f.e. LC_TIME are still valid. It is not required to have LC_CTYPE for locale. You need

Re: Request for review: locale aliases support for libc

hi, On Tue, Aug 29, 2000 at 07:00:47PM +0400, Andrey A. Chernov wrote: Why you always check LC_CTYPE existance only? It may not exist but other locale parts, f.e. LC_TIME are still valid. It is not required to have LC_CTYPE for locale. I just randomly selected one of files which is exists

Re: Request for review: locale aliases support for libc

Alexey Zelkin wrote: You need to check LC_* existence corresponding to setlocale() request made. What to check if LC_ALL request is given ? LC_ALL overrides all other LC_* variables. If it is set, there is no need to check anything else. Then you should check all other LC_*, and then

Re: Request for review: locale aliases support for libc

Alexey Zelkin wrote: You need to check LC_* existence corresponding to setlocale() request made. What to check if LC_ALL request is given ? LC_ALL overrides all other LC_* variables. If it is set, there is no need to check anything else. Then you should check all other

Re: Request for review: locale aliases support for libc

On Tue, Aug 29, 2000 at 06:24:49PM +0300, Alexey Zelkin wrote: You need to check LC_* existence corresponding to setlocale() request made. What to check if LC_ALL request is given ? Just repeat the same procedure as regular algorithm gives for LC_ALL processing. -- Andrey A. Chernov

Re: Request for review: locale aliases support for libc

hi, On Tue, Aug 29, 2000 at 05:19:56PM +0100, Konstantin Chuguev wrote: Perhaps you should check presence of any of the following files in a locale directory: LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME, LC_NUMERIC ? :) and proceed if any of them has been found... Sure. I do

Re: Request for review: locale aliases support for libc

Alexey Zelkin wrote: I am trying to realize "is requested locale physicaly present on this system" or it's just an alias. Can you not revert the test: if the locale is present in the alias file, then it obviously is an alias; otherwise it should be present on the system? Just a quick

Re: Request for review: locale aliases support for libc

Marcel Moolenaar wrote: Alexey Zelkin wrote: I am trying to realize "is requested locale physicaly present on this system" or it's just an alias. Can you not revert the test: if the locale is present in the alias file, then it obviously is an alias; otherwise it should be present on

Re: Request for review/comments - new option for uname(1)

On Wednesday, August 09, 2000, Mark Ovens wrote: The only thing I couldn't work out is why sysctl() adds 5 spaces after the date sub-string, so I've haven't stripped them out (hence the indented third line). sysctl() does not do that, that's what the data in the kernel is. Look at

Re: Request for review/comments - new option for uname(1)

On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote: Is there any reason why this is unacceptable and could not be committed? Because it can be done with an awk/sed script? -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:+ a--- C++ UB$ P+ L- E--- W+ N-- !o ?K

Re: Request for review/comments - new option for uname(1)

On Wed, Aug 09, 2000 at 02:33:44PM -0400, Will Andrews wrote: On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote: Is there any reason why this is unacceptable and could not be committed? Because it can be done with an awk/sed script? I'll forget about it then. I only did it

Request for review/comments - new option for uname(1)

The output of ``uname -a'' appears in hundreds of e-mails and PRs yet the output format is not ideal for this (especially e-mail in 80-column mail readers) as it is a single line. Attached is a patch for an enhancement I've made that adds a new option ``-A'' (rather than change ``-a'') that

Re: Request for review (LPDEST vs PRINTER)

On Wed, Aug 02, 2000 at 09:35:23PM -0400, Garance A Drosihn wrote: The other printing-system alternative is LPRng (which people can install from ports). LPRng does add the 'lpstat' command, in addition to replacing lpr/lpq/lprm. And if I am reading this code right, it does check LPDEST for

Request for review

I originally sent this to -committers but was advised that the maintainers and -hackers or -current was more appropriate. I've posted some patches for PR 14682 which include some changes to the source code for lpr(1), lprm(1) etc. Could someone review them for me please, especially the C code.

Re: Request for review (LPDEST vs PRINTER)

At 10:39 PM +0100 8/2/00, Mark Ovens wrote: I originally sent this to -committers but was advised that the maintainers and -hackers or -current was more appropriate. I've posted some patches for PR 14682 which include some changes to the source code for lpr(1), lprm(1) etc. Could someone review

Re: request for review, patch to specfs to fix EOF condition alignmentwith buffer

On Wed, 22 Sep 1999, Bruce Evans wrote: This is a request for a review. This patch fixes a bug in specfs It is a bit over-commented, and returns wrong error codes for EOF. This is certainly not over commented in my opinion. I wish more people would comment as much as Matt does

request for review, patch to specfs to fix EOF condition alignment with buffer

This is a request for a review. This patch fixes a bug in specfs relating to dealing with the EOF condition of a block device. If the EOF occurs in the middle of a block, specfs was not properly calculating the truncation for the I/O. This problem was first found by Tor

request for review, patch to specfs to fix EOF condition alignment with buffer

This is a request for a review. This patch fixes a bug in specfs relating to dealing with the EOF condition of a block device. If the EOF occurs in the middle of a block, specfs was not properly calculating the truncation for the I/O. This problem was first found by Tor

Re: request for review, patch to specfs to fix EOF condition alignment with buffer

Once this patch is committed, the only problem we will have is in recognizing the write-EOF case, which I will have a recommendation for after this patch goes in. ...and the lack of error code returns on write. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL

Re: request for review: move of /var/cron/log to /var/log/cron.log

On Mon, Sep 06, 1999 at 02:12:53PM -0700, David Greenman wrote: I think they should all have .log since there can be subdirectories and it makes the files more easily identifiable. You're right ... I understand ... -- Andreas Klemm

Re: request for review: move of /var/cron/log to /var/log/cron.log

Uhm, well, yes, but I just committed the patch for /var/cron/log to /var/log/cron and not cron.log. So I guess that Andreas' idea has been incorporated. Nick On Mon, Sep 06, 1999 at 02:12:53PM -0700, David Greenman wrote: I think they should all have .log since there can be

Re: request for review: move of /var/cron/log to /var/log/cron.log

Every time they ask you why we do things the way we do, and after you have taken the N minutes to explain it, ask them to go ask Sun the same question, out of fairness to FreeBSD. It might put these ``Sun is the world'' guys back into thier place. Or atleast it might get them off your

request for review: move of /var/cron/log to /var/log/cron.log

Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. Cheers, Nick Index: UPDATING === RCS file:

Re: request for review: move of /var/cron/log to /var/log/cron.log

Nick Hibma wrote: Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. The only thing I don't like about this is that it introduces a point of incompatibility

Re: request for review: move of /var/cron/log to /var/log/cron.log

:Nick Hibma wrote: : : Please review the following patch to get all the log files in one place. : The commit will be accompanied by a HEADS UP. If no one objects I will : commit this in a couple of days. : : The only thing I don't like about this is that it introduces a point of

Re: request for review: move of /var/cron/log to /var/log/cron.log

Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. The only thing I don't like about this is that it introduces a point of incompatibility between FreeBSD

Re: request for review: move of /var/cron/log to /var/log/cron.log

Doug wrote: Nick Hibma wrote: Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. The only thing I don't like about this is that it introduces a point

Re: request for review: move of /var/cron/log to /var/log/cron.log

The only thing I don't like about this is that it introduces a point of incompatibility between FreeBSD and other unices, and I'm not sure the I think there was a lot of this sort of "compatibility" lost when BSD introduced its whole hier(7) enforced subtree scheme, and about the only

Re: request for review: move of /var/cron/log to /var/log/cron.log

Nick Hibma wrote: Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. The only thing I don't like about this is that it introduces a point of

Re: request for review: move of /var/cron/log to /var/log/cron.log

Mike Smith wrote: Don't get me wrong, my boss/cow orkers/etc. aren't morons, I would just like to avoid gratuitous differences for their own sake. "FreeBSD is not Solaris". The differences aren't "gratuitous" because we're not trying to be "like Solaris" in the first place. The

2nd request for review for vlan changes

This is a second request for review for my proposed if_vlan updates. Since I tweaked a couple of different things, I placed a tarball with the sources at http://www.freebsd.org/~wpaul/VLAN/vlan.tar.gz (or, for those of you with freebsd.org accounts, ~wpaul/public_html/VLAN/vlan.tag.gz

Re: 2nd request for review for vlan changes

What is vlan? Tnks, Amancio To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

In article 18961.920316...@critter.freebsd.dk, Poul-Henning Kamp p...@critter.freebsd.dk wrote: It should have been done with a simple ascii string instead. The drivers are much better at chewing on it than the generic code, it would be simpler to understand, simpler to implement, you

Re: Request for review: changes to if_vlan.c

Amen, brother! Get it said! People who claim that strings are too slow would benefit greatly from spending a few days with the profiler. Now I'll stir the other pot and say that performance isn't the issue- the issue is that there's nothing that says that strings and identifiers are always

Re: Request for review: changes to if_vlan.c

In message pine.lnx.4.04.9903031215150.25376-100...@feral-gw, Matthew Jacob w rites: Amen, brother! Get it said! People who claim that strings are too slow would benefit greatly from spending a few days with the profiler. Now I'll stir the other pot and say that performance isn't the

Re: Request for review: changes to if_vlan.c

Matthew Jacob wrote: Now I'll stir the other pot and say that performance isn't the issue- the issue is that there's nothing that says that strings and identifiers are always easier to use and/or understand than numbers. They are a lot more extensible, though. With strings, you generally

Re: Request for review: changes to if_vlan.c

Now I'll stir the other pot and say that performance isn't the issue- the issue is that there's nothing that says that strings and identifiers are always easier to use and/or understand than numbers. They are a lot more extensible, though. With strings, you generally have to modify and

  1   2   >