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
|>|updat
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 s
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 is
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 i
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 your
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
__
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
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
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 trivi
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). This is not trivial since
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 y
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
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 ful
On 03/07/11 19:27, Freddie Cash wrote:
On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehorn 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 agai
On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehorn 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 suggest a better wa
On 03/07/11 14:14, Freddie Cash wrote:
On Mon, Feb 28, 2011 at 6:49 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 wo
On Mon, Feb 28, 2011 at 6:49 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 2 week
On Fri, 4 Mar 2011 12:24:20 -0800 Freddie Cash 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> statio
On 04/03/2011 20:24, Freddie Cash wrote:
> On Mon, Feb 28, 2011 at 6:49 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 objec
On Mon, Feb 28, 2011 at 6:49 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 2 week
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 to
2011/3/3 Paul Schenkeveld :
> 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
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 whic
In article <4d6e6c43.4010...@freebsd.org>
Nathan Whitehorn 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 there aren't
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
On 03/02/11 10:06, TAKAHASHI Yoshihiro wrote:
In article<4d6bb5e3.6020...@freebsd.org>
Nathan Whitehorn 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
In article <4d6bb5e3.6020...@freebsd.org>
Nathan Whitehorn 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
> like to pull this sw
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 objections,
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 swit
On 02/28/11 08:56, Bruce Cran wrote:
On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehorn 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 bo
On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehorn 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 nice. For example Debia
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 in
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
___
freebsd-current@freebsd.org
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
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
com
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:
http://www.dellroad.org/dro
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
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 fi
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
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.
<[EM
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
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 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 are
On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote:
> < 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 PO
< 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 interfaces: fork(), setsid(), chdir(), open(), dup2(),
and close(). It i
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 usag
< 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 living
> textbook to other programmers. They should be as `good' as
> poss
"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 taker
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, M
|> 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
|> 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. I
< 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 C
multibyte/wide character API.
> Actually NetBSD does not export .
N
-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 C
|> 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
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
|> 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; u
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--;
: |
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 infin
[ 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
lib
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 p
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 thou
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
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. Cherno
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
hi,
On Tue, Aug 29, 2000 at 04:35:04PM +0100, Konstantin Chuguev 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
> ch
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 th
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
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 t
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 in
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 shou
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 functiona
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 /usr/share/loca
Paul Richards wrote:
> Mark Ovens wrote:
> >
> > 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
Mark Ovens wrote:
>
> 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 f
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
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
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 src/s
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 split
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 f
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
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.
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.
> 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.
I didn't have time to review this
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. To
> This problem was first found by Tor. Tor's example creates
> an oddly-sized VN partition and then dd's from it. Without the
> patch the dd believes that it can read 2880 sectors. With the
> patch it correctly reads the last (truncated) block.
Actually, the problem was discus
>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 PROT
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. To
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 su
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 http://www.FreeBSD.O
At 8:09 PM +0200 9/6/99, Andreas Klemm wrote:
>On Sun, Sep 05, 1999 at 11:32:35AM +0200, Nick Hibma wrote:
> > -/var/cron/log 600 3 100 * Z
> > +/var/log/cron.log 600 3 100 * Z
> > /var/log/amd.log 664 7 100
>On Sun, Sep 05, 1999 at 11:32:35AM +0200, Nick Hibma wrote:
>> -/var/cron/log 600 3 100 * Z
>> +/var/log/cron.log 600 3 100 * Z
>> /var/log/amd.log664 7 100 * Z
>> /var/log/kerberos.log
Doing it for the cron file, yes, no probs, sounds like a great idea,
but for the rest of the files I'd leave it as is. Let's have a look at
it later on when we have some idea of what things break when changing
names and loations of log files.
Ok?
Nick
On Mon, 6 Sep 1999, Andreas Klemm wrote:
On Sun, Sep 05, 1999 at 11:32:35AM +0200, Nick Hibma wrote:
> -/var/cron/log600 3 100 * Z
> +/var/log/cron.log600 3 100 * Z
> /var/log/amd.log 664 7 100 * Z
> /var/log/kerberos.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
> > "FreeBSD is not Solaris". The differences aren't "gratuitous" because
> > we're not trying to be "like Solaris" in the first place. The
> > differences that exist do so because our idea of "sensible" doesn't
> > agree with Sun's. The real discriminating factor there is that we do
> > things
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
> 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
differences that exis
"Rodney W. Grimes" wrote:
> 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
> 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 intr
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
> 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 O
1 - 100 of 126 matches
Mail list logo
