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
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
> ../../../dev/ie/if_ie
> 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 f
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
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 PR
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 final
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 setpg
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'
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 th
>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:1
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
> requir
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 men
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 m
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 it
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 t
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 wi
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).
> >
> >
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 ta
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 Elisc
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 mai
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
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-draggin
> 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 func
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, it'
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 fr
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
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
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 fu
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).
>> 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 dinne
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.
>
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,
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
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 from
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
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, Kennet
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 28
> 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
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 i
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
> e
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 p
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
cvsup on 2002.02.28.20.00 (GMT+1) with build and install.
Last day spent with Scott to try to install external usb to ide
hd, a lot of debug enabled (usb, umass, ugen).
Here my collection of error messages. Going to cvsup again.
Machine rebooted automagically _without_ any other message, so
I lo
> 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 th
On 01-Mar-02 Jun Kuriyama wrote:
> 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 fail
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 rev
>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
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?
>>
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
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.
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 PR
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, min
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
>:stuf
:>
:>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 f
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 op
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 i
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 p
>>: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 tha
69 matches
Mail list logo
