On Wed, 27 Feb 2002, Matthew Dillon wrote:
:/*
: * Note: the volatile below does not REQUIRE that the argument be
: * volatile, but rather ony says that it is OK to use a volatile * i
: * there. Same for the const. I know a const volatile sounds strange
: * but it only indicates that either
On Wed, 27 Feb 2002, Julian Elischer wrote:
ok so I leave it to other people to fix LINT
I'm not going near it any more
one small example:
../../../dev/ie/if_ie.c:1471: warning: passing arg 1 of pointer to
function discards qualifiers from pointer target type
It would be nice to see this version of perl in -CURRENT. It would help
ease the development of mod_perl-2.0 by not having to install the port
and it just makes sense considering the bleeding-edge of the rest of the
system.
Coming RSN. Maybe this weekend.
M
--
o Mark Murray
\_
On Thu, 28 Feb 2002, Seigo Tanimura wrote:
On Thu, 28 Feb 2002 01:39:11 +0900,
Takanori Saneto [EMAIL PROTECTED] said:
Takanori Can you look into PR kern/29844 as well?
Takanori I think after your fix, it should fail even when invoked by super
Takanori user.
The superuser fails as
On Wed, 27 Feb 2002, Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew Dillon writes:
: Sometimes features in early boot can be adjusted by breaking into DDB
: and w/l changing the sysctl variable, but perhaps not in this case.
I think this is an excellent idea. I have many
when trying to build a kernel this morning I get:
cc1: wanings being treated as errors
/usr/sys/src/dev/aic7xxx/aicxxx7.c In function ahc_calc_residual':
/usr/sys/src/dev/aic7xxx/aicxxx7:5757 warning 'resid' might be an
uninitialized function
*** Error code 1
does anyone know if this has been
Sorry, I forgot to get kernel core for this (today's -current)...
panic: Assertion td-td_proc-p_stat == SRUN || td-td_proc-p_stat == SZOMB ||
td-td_proc-p_stat == SSTOP failed at ../../../kern/kern_mutex.c:126
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED]
On 26-Feb-02 Julian Elischer wrote:
On Tue, 26 Feb 2002, John Baldwin wrote:
My suggestion will be to back it out. I would rather not have to make said
suggestion. Can you please try to fit this into the existing framework
rather
than ripping it all up? We need to finalize and test
On Thu, 28 Feb 2002 22:14:56 +1100 (EST),
Bruce Evans [EMAIL PROTECTED] said:
Takanori Can you look into PR kern/29844 as well?
Takanori I think after your fix, it should fail even when invoked by super
Takanori user.
The superuser fails as well.
bde setpgrp() is the same as setpgid() in
On Wed, 27 Feb 2002, George V. Neville-Neil wrote:
I think we need to avoid the concept of imposing some modicum of
structure. If we create structure it is because we need it. Just like
software. There was a good comment recently about software gets
created to scratch an itch. I'd say
I've been working from Gordon Tetlow's work on this, for the past few
weeks. I have managed to get most everyting up to network_pass3 in
/etc/rc. It's still very much in development, but it's quite usable and
I use it to boot my system on a daily basis.
I chose to go a slightly different route
Date: Thu, 28 Feb 2002 22:51:02 +0900
From: Jun Kuriyama [EMAIL PROTECTED]
Sorry, I forgot to get kernel core for this (today's -current)...
panic: Assertion td-td_proc-p_stat == SRUN || td-td_proc-p_stat == SZOMB ||
td-td_proc-p_stat == SSTOP failed at ../../../kern/kern_mutex.c:126
I have
Thanks for the hard work, Mike!
Mike Makonnen wrote:
- Converging startup scripts before the rest of the system is converted
will be a nightmare because there are too many differences.
Examples why:
- The -w switch is deprecated in FreeBSD, and NetBSD still
requires
On Thu, Feb 28, 2002 at 08:39:33AM -0800, Mike Makonnen wrote:
I chose to go a slightly different route than Gordon, in that I have not
tried to make the scripts compatible with NetBSD (His scripts include
conditionals for NetBSD, mine don't). These are my reasons.
The point you are missing
What I mean by imposing structure is:
- Identify patterns of development and structure that seem to have evolved
naturally as part of the maturing of the FreeBSD Project
- Determine which patterns tend to result in the most productive and
parallel development efforts, not to mention
On Thu, 28 Feb 2002, George V. Neville-Neil wrote:
What I mean by imposing structure is:
- Identify patterns of development and structure that seem to have evolved
naturally as part of the maturing of the FreeBSD Project
- Determine which patterns tend to result in the most
An updated version of the ATAPI/CAM patches is available from
http://www.cuivre.fr.eu.org/~thomas/atapicam/
This version contains no functional changes, but synchronize with
recent modifications to the generic ATAPI code.
As always, I would be interested in any feedback. Specifically, there
is
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally even if not perfect.. it's better than nothing and we should
probably commit something like it. or based on
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote:
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally even if not perfect.. it's better than
yes but thete are subcommits that you could go ahead with...
the td_ucred stuff could have been checked in directly into -current.
On Thu, 28 Feb 2002, John Baldwin wrote:
On 26-Feb-02 Julian Elischer wrote:
On Tue, 26 Feb 2002, John Baldwin wrote:
My suggestion will be to back
Not to put too fine a point on it, but, I don't see how this can
possibly justify preventing me from committing my critical_*() stuff.
You've just stated publically that your preemption stuff is unusable
as it currently stands. Why am I supposed to wait an arbitrary period
of
It seems Kenneth D. Merry wrote:
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote:
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally
On 28-Feb-2002 (06:57:50/GMT) Riccardo Torrini wrote:
The only difference in /dev was -ugen{0,0.1,0.2} +xpt0 :(
# camcontrol rescan 0
Re-scan of bus 0 was successful
# camcontrol devlist -v
scbus0 on umass-sim0 bus 0:
scbus-1 on xpt0 bus 0:
at scbus-1 target -1
I think it's better to commit it now and have it fixed in situ.
It's new functionality so committing it with bugs will not break anyone.
it will however get more work done on it and more testing.
On Thu, 28 Feb 2002, Kenneth D. Merry wrote:
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
I'd expect this sort of foot-dragging if the patch were intrusive to the
ATA drivers but its not.
--
| Matthew
In message [EMAIL PROTECTED], Jul
ian Elischer writes:
I think it's better to commit it now and have it fixed in situ.
It's new functionality so committing it with bugs will not break anyone.
it will however get more work done on it and more testing.
[...]
Well you are one of the main CAM
It seems Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
Read the rest of my mail, the problem is not the patches as much
as it is all the
On Thu, Feb 28, 2002 at 02:45:04PM -0500, Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
I'd expect this sort of foot-dragging if
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the front-ends to cdrecord will work. It's much nicer
than memorizing mkisofs commandline switches :-)
What
Poul-henning.
What crack are you on?
Have you looked at the patches in question?
They are small and non-intrusive.
We are relying on the ATA maintainer to tell us whether they
are dangerous, but they are so small that we should look at
fast-tracking them if possible.
Even if it was broken,
where dod sis post his email..?
I never saw it
On Thu, 28 Feb 2002, Kenneth Culver wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the
On Thu, 2002-02-28 at 12:57, Sxren Schmidt wrote:
It seems Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
Read the rest of my
It seems Kenneth Culver wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the front-ends to cdrecord will work. It's much nicer
than memorizing mkisofs
It seems Scott Long wrote:
As I have stated several times, I have no problem with ATAPI being
sent through CAM as long as the usual way stays (some of us cannot
afford the weight of those extra layers, nor loose functionality).
I'd do the integration somewhat differently to even further
On Thu, 2002-02-28 at 14:06, Søren Schmidt wrote:
It seems Scott Long wrote:
As I have stated several times, I have no problem with ATAPI being
sent through CAM as long as the usual way stays (some of us cannot
afford the weight of those extra layers, nor loose functionality).
I'd do
What functionality is lost by this ability?
Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
More of us are getting wives we need to take out to dinner
It seems Justin T. Gibbs wrote:
What functionality is lost by this ability?
Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
Exactly.
More of us
It seems Scott Long wrote:
I'm mainly raising my hand to take the abuse that will no doubt happen
once in a while.
Sure, maybe we should make Thomas a committer so he could look after
it himself ? Interested ? Got the time ? I'm all ears for volounteers...
Ummm, I'm
Wow /that's/ a thread ;)
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
First of all I'd like to make two points:
* Søren is doing a great job as ATA maintainer, and it would be a
Bad Thing to have him quit;
* I am
Le 2002-02-28, Søren Schmidt écrivait :
I have no problem with you doing it, I was just fishing for getting
Thomas into the net also, we need all the hands we can get :)
As I mentioned I am entirely willing to take charge of the care
and feeding of the bugs I wrote.
Thomas.
--
[EMAIL
I think Thomas is doing here a quite good job and it is also to him to
decide to include his sources and maybe maintain them. The ata sources have
changed a lot the last weeks, so until Thomas thinks his sources are under
heavy development too, both should do their jobs and we've some patches
We have CVS
Why not commit the prototype now and update it as people get the corner
cases worked out?
The code doesn't interfere with either the CAM system or the ATAPI system
that I can see.
On Thu, 28 Feb 2002, Jan Stocker wrote:
I think Thomas is doing here a quite good job and it is also
On Thu, 2002-02-28 at 23:15, Julian Elischer wrote:
We have CVS
Okay.. thats a piece software..
Why not commit the prototype now and update it as people get the corner
cases worked out?
If Thomas can and will maintain it, ok... else read my comment from my
last mail...
The code doesn't
Umm, I don't remember where he posted it, but it wasn't posted privately.
Most likely since I'm using pine, it was posted to freebsd-current and
freebsd-scsi.
Ken
On Thu, 28 Feb 2002, Julian Elischer wrote:
where dod sis post his email..?
I never saw it
On Thu, 28 Feb 2002, Kenneth
Hi,
Out of curiousity I plugged a webcam in my -current box. After browsing the
mailing lists and the net for a while I found that there has been talk here
about a usb driver for webcams based on this VLSI Vision CPiA chip. This is
the message the webcam generates after plugging it in:
Feb
Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did
patches for this long ago, but noone picked it up as a port...
I remember you saying that you had these, but you weren't willing to
release them for some reason; something to do with the GPL...
What functionality is lost by
Apparently a recent change in the make file(s) in -Current causes normal
warning messages to be treated as errors (for un-initialized variables) for
example, which stops the build process. Yes the file(s) with errors can be
edited my hand to set the offending variable to a 'default' value, but
On Thu, Feb 28, 2002 at 06:31:14PM -0500, Glenn Gombert wrote:
Apparently a recent change in the make file(s) in -Current causes normal
warning messages to be treated as errors (for un-initialized variables) for
example, which stops the build process. Yes the file(s) with errors can be
this was fixed.. (many warnings removed)
try resup and reconfig
On Thu, 28 Feb 2002, Glenn Gombert wrote:
Apparently a recent change in the make file(s) in -Current causes normal
warning messages to be treated as errors (for un-initialized variables) for
example, which stops the build
At Thu, 28 Feb 2002 17:10:25 + (UTC),
David Wolfskill wrote:
Sorry, I forgot to get kernel core for this (today's -current)...
panic: Assertion td-td_proc-p_stat == SRUN || td-td_proc-p_stat == SZOMB ||
td-td_proc-p_stat == SSTOP failed at ../../../kern/kern_mutex.c:126
I have yet to
Certainly -- the intent that I expressed in my original e-mail was to fish
for people's thoughts on the issue, which would then be codified in some
form. I'm interested in hearing a little more back on how people feel
about the notion of how larger projects should coordinate work given the
At Fri, 1 Mar 2002 01:34:17 + (UTC),
John Baldwin wrote:
That's bad juju panic. :) Are you using witness? If so, did you get a printf
about sleeping with a lock held?
I think I did not get lock warning just before this assertion
failure. But on my environment, I got this lock order
Date: Fri, 01 Mar 2002 10:47:09 +0900
From: Jun Kuriyama [EMAIL PROTECTED]
At Fri, 1 Mar 2002 01:34:17 + (UTC),
John Baldwin wrote:
That's bad juju panic. :) Are you using witness? If so, did you get a printf
about sleeping with a lock held?
I think I did not get lock warning just
David Wolfskill wrote:
Date: Fri, 01 Mar 2002 10:47:09 +0900
From: Jun Kuriyama [EMAIL PROTECTED]
At Fri, 1 Mar 2002 01:34:17 + (UTC),
John Baldwin wrote:
That's bad juju panic. :) Are you using witness? If so, did you get a printf
about sleeping with a lock held?
I think I did not
At Fri, 1 Mar 2002 01:34:17 + (UTC),
John Baldwin wrote:
That's bad juju panic. :) Are you using witness? If so, did you get a printf
about sleeping with a lock held?
I forgot to mention, I'm using WITNESS and WITNESS_SKIPSPIN options.
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC,
On 28-Feb-02 Matthew Dillon wrote:
Not to put too fine a point on it, but, I don't see how this can
possibly justify preventing me from committing my critical_*() stuff.
You've just stated publically that your preemption stuff is unusable
as it currently stands. Why am I
On 01-Mar-02 David Wolfskill wrote:
Date: Fri, 01 Mar 2002 10:47:09 +0900
From: Jun Kuriyama [EMAIL PROTECTED]
At Fri, 1 Mar 2002 01:34:17 + (UTC),
John Baldwin wrote:
That's bad juju panic. :) Are you using witness? If so, did you get a
printf
about sleeping with a lock held?
I
On Thu, 2002-02-28 at 09:02, Terry Lambert wrote:
Thanks for the hard work, Mike!
Thanks, nice to know someone appreciates it. Every one has their own
ideas about how it _should_ be done, so I expected I'd get flamed for
not pleasing everyone. OTOH it's been less than 24 hours since I posted
:
:
:On 28-Feb-02 Matthew Dillon wrote:
: Not to put too fine a point on it, but, I don't see how this can
: possibly justify preventing me from committing my critical_*() stuff.
: You've just stated publically that your preemption stuff is unusable
: as it currently stands. Why
While I haven't specifically tested this patch it looks
reasonable to me. Are you going to do an engineering/commit
cycle with it?
-Matt
Matthew Dillon
[EMAIL
On Thu, 2002-02-28 at 09:23, David O'Brien wrote:
On Thu, Feb 28, 2002 at 08:39:33AM -0800, Mike Makonnen wrote:
I chose to go a slightly different route than Gordon, in that I have not
tried to make the scripts compatible with NetBSD (His scripts include
conditionals for NetBSD, mine
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:Because the critical_* changes you are doing don't match up to the overall
:design. See my mail to -arch for more on that though. At some point in the
:future I think that this work can fit in rather well to the cpu_critical_foo
:stuff
:
:I strongly disagree. I have yet to see any technical description of
:this so-called overall design that shows any incompatibility, and what
:I decide to do with my time is my business.
:
:Matt,
:
:That particular protest is rather hollow, considering that you were
:one of the
Hello all,
I am curious about the file sizes of the backing files for extend attributes.
I have compiled a custom kernel that has both extended attribute support and
acl support. I can sucessfully add and remove acls for files. I am quite
impressed. I used a sparse backing file (i.e. no -p
On Thu, 28 Feb 2002, Galen Sampson wrote:
Is there any reason the file is shown as being 544,094,812 bytes? I'm sure it
is actually only 50K. Just curious if this is something a developer should
look at before the release (this is obviously quite minor compared to other
things).
This is
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
:
:I strongly disagree. I have yet to see any technical description of
:this so-called overall design that shows any incompatibility, and what
:I decide to do with my time is my business.
:
:Matt,
:
:That particular protest is
:John has been consistently chugging along on the job all the way.
:At this point in time, until he is officially unseated John is our
:designated SMPng architect and his word is pretty final.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
Oooh... so you mean that since I was
67 matches
Mail list logo
