Re: controversial fix or some errors breaking LINT
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 is acceptable. : */ :voidbcopy __P((volatile const void *from, volatile void *to, size_t :len)); I really don't like this. I mean, it will work but I really don't like this. Volatile in C will effectively prevent optimization of read and write accesses to the data the pointer is pointing at. Of course, this is bcopy(), which we implement in assembly, so again it will work for bcopy(). But it sets a very bad coding precedent. Volatile semantics also prevents optimizations in the assembly versions. i586_bcopy already does extensive optimizations involving out of order loads to prefetch cache lines. i586_bzero does even more volatile- unfriendly things for (dubious) alignment tricks. Even overlapping bcopies break volatile semantics (by copying backwards in some cases). Similarly for memcpy. bcopy and memcpy in the kernel should have the same interface as in userland. I think the correct fix is to always use bus space for hardware accesses, and only use volatile elements or whole volatile structs for non-hardware variables very rarely. The bus space functions avoid optimizations that are only valid for ordinary memory just by not using optimizations that are not usefule for device memory. Volatile variables don't work so well for SMP systems since you often need to lock them anyway and the lock makes them nonvolatile. BTW, C's volatile semantics do not protect you from invalidly bcopy'ing a non-volatile struct with volatile elements. C just looks at the qualifiers on the pointer to the struct and doesn't look inside the struct. Bcopy'ing such a struct gives undefined behaviour, so the compiler is permitted to detect this error. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: controversial fix or some errors breaking LINT
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.c:1480: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1483: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type ../../../dev/ie/if_ie.c:1508: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type it's so obviously the right way that I'm amazed that there can even be discussion. (except that I know Bruce didn't lik eit before) (he and jhb just actualy created more errors in LINT by removing a volatile on the definition of bzero in the kernel.) (the above fatal errors are new and brought to you by the people who just did that removal) We just unshot one of the messengers. Breaking bzero for the i386 case didn't affect other arches. remember folks.. this is the kernel here.. what Posix says doesn't count INSIDE the kernel. Actually, it does for bcopy. We use the same interface for all the string functions kernel so that experience with it them userland can be reused and vice versa. We deal wit devices inside the kernel. we have a LOT of volatile stuff. It may be worth creating a vbcopy and vbzero to handle volatile stuff then. (But I think it's a stupid thing to need to do) the bus-space mess should have stuff to do this but no-one who understands it has had teh energy to actually fix this stuff with it. so we are stuck with a broken LINT. Most drivers aren't affected by this. This is because: - most of them already use bus-space. - most of the drivers that don't use bus-space only support PIO devices, so they don't need volatile qualifiers for device memory. - most of the others (if there are any left other than if_le) don't use volatiles carefully to a fault like if_ie. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl5.6.1
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 \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
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 well. setpgrp() is the same as setpgid() in FreeBSD, and the POSIX.1-200x-draft7 documentation for setpgid() doesn't seem to have any special cases for the superuser, so I think the documentation change in the PR is correct. POSIX now has setpgrp(), but it is quite different from setpgid() :-(. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
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 of these tunables in
the cardbus/oldcard code and it has helped me to diagnose many
problems. All my stuff runs after SI_SUB_TUNABLES, so that's not an
issue. Of course, not much happens before SUB_TUNABLES, but Peter's
changes look like they might be one of them.
Some older changes by Peter actually broke this feature. I ran into this
for nbuf. I set nbuf in ddb early (using a de-rotted version of db_elf.c
from the Attic to find nbuf since db_kld.c is too broken to work early),
but init_param.c undid the change.
The patch initializes nbuf (and many other things) statically again.
The only losses are slight bloat of the data section and the ability
to use non-constant expressions for certain macros if you #define them.
E.g., in -current you can #define NBUF in terms of maxusers although
that would be silly (I think physmem is not in scope so more sensible
definitions don't work). However, the patch retains the ability to
set MAXFILES using a funky expression. Most variables aren't ifdefed
uglyly enough to support this complication. E.g., the expression for
NPROC in terms of maxusers is fixed. The patch uses this expression
directly.
%%%
Index: subr_param.c
===
RCS file: /home/ncvs/src/sys/kern/subr_param.c,v
retrieving revision 1.52
diff -u -2 -r1.52 subr_param.c
--- subr_param.c6 Feb 2002 01:19:19 - 1.52
+++ subr_param.c23 Feb 2002 07:44:45 -
@@ -56,31 +56,27 @@
#defineHZ 100
#endif
-#defineNPROC (20 + 16 * maxusers)
#ifndef NBUF
-#define NBUF 0
-#endif
-#ifndef MAXFILES
-#defineMAXFILES (maxproc * 2)
+#defineNBUF 0
#endif
-inthz;
+inthz = HZ;
inttick;
-inttickadj; /* can adjust 30ms in 60s */
-intmaxusers; /* base tunable */
-intmaxproc;/* maximum # of processes */
-intmaxprocperuid; /* max # of procs per user */
-intmaxfiles; /* sys. wide open files limit */
-intmaxfilesperproc;/* per-proc open files limit */
-intncallout; /* maximum # of timer events */
-intnbuf;
+inttickadj;
+intmaxusers = MAXUSERS;/* base tunable */
+intmaxproc;/* maximum number of processes */
+intmaxprocperuid; /* max number of procs per user */
+intmaxfiles; /* system wide limit on open files */
+intmaxfilesperproc;/* per-process limit on open files */
+intncallout; /* maximum number of timer events */
+intnbuf = NBUF;
intnswbuf;
-intmaxswzone; /* max swmeta KVA storage */
-intmaxbcache; /* max buffer cache KVA storage */
-u_quad_t maxtsiz;/* max text size */
-u_quad_t dfldsiz;/* initial data size limit */
-u_quad_t maxdsiz;/* max data size */
-u_quad_t dflssiz;/* initial stack size limit */
-u_quad_t maxssiz;/* max stack size */
-u_quad_t sgrowsiz; /* amount to grow stack */
+intmaxswzone = VM_SWZONE_SIZE_MAX; /* max swmeta KVA storage */
+intmaxbcache = VM_BCACHE_SIZE_MAX; /* max buffer cache KVA storage */
+u_quad_t maxtsiz = MAXTSIZ;/* max text size */
+u_quad_t dfldsiz = DFLDSIZ;/* initial data size limit */
+u_quad_t maxdsiz = MAXDSIZ;/* max data size */
+u_quad_t dflssiz = DFLSSIZ;/* initial stack size limit */
+u_quad_t maxssiz = MAXSSIZ;/* max stack size */
+u_quad_t sgrowsiz = SGROWSIZ; /* amount to grow stack */
/*
@@ -92,5 +88,5 @@
/*
- * Boot time overrides that are not scaled against main memory
+ * Boot time overrides that are not scaled against main memory.
*/
void
@@ -98,34 +94,21 @@
{
- hz = HZ;
TUNABLE_INT_FETCH(kern.hz, hz);
tick = 100 / hz;
tickadj = howmany(3, 60 * hz); /* can adjust 30ms in 60s */
-#ifdef VM_SWZONE_SIZE_MAX
- maxswzone = VM_SWZONE_SIZE_MAX;
-#endif
TUNABLE_INT_FETCH(kern.maxswzone, maxswzone);
-#ifdef VM_BCACHE_SIZE_MAX
- maxbcache = VM_BCACHE_SIZE_MAX;
-#endif
TUNABLE_INT_FETCH(kern.maxbcache, maxbcache);
- maxtsiz = MAXTSIZ;
TUNABLE_QUAD_FETCH(kern.maxtsiz, maxtsiz);
- dfldsiz = DFLDSIZ;
TUNABLE_QUAD_FETCH(kern.dfldsiz, dfldsiz);
- maxdsiz = MAXDSIZ;
TUNABLE_QUAD_FETCH(kern.maxdsiz, maxdsiz);
-
Kernel Build Fails In -Current
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 fixed yet ?? Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Assertion faild at kern_mutex.c
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] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 the design before we hardcode too many assumptions about the implementation into the interface. You have pointed out some issues with the current interface which are valid and I would like to address those, however, there are still changes to the MI implementation that need to go in once it doesn't crash right and left. If you wish I could commit the code and make current a living hell for everyone, but my ethics don't permit me to test code that I know is broken. You know john, I wish you would commit more often and let it break things occasionally. It's REALLY HARD for anyone else to comment and help if you keep doing on P4 which is NOT the project Souce control system. Even with cvsup assistanace, it's just no-where near as convenient as having it checked in. And after you HAVE checked it in, others can help find and fix problems.. as it is you are on your own. (This is the reason I will shortly check in the KSE diffs on a branch) *sigh* Preemptive kernels don't even make it out of single user mode for SMP machines, ok? We aren't talking minor breakage here, we are talking _extreme_ breakage. If people want to play with it, preempt.patch on freefall is updated via a cron job every half hour or so. Unfortunately, however, it's in a limbo atm due to KSE and needing to sort out how the priorities are going to work. It will really be better to let KSE settle into the scheduler first adn then add preemption to the scheduler itself afterwards. The reason I'm not pushing preemption into the tree fully (I've already committed half of the original patch) is that there is other work (proc locking for example) that gets us more bang for the buck. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: setpgrp(1, 1) does not FAIL
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 FreeBSD, and the POSIX.1-200x-draft7 bde documentation for setpgid() doesn't seem to have any special cases for bde the superuser, so I think the documentation change in the PR is correct. While we are here, it would be even better to clarify the requirements of setpgid(2) like this: The affected process must: o be a descendant of the invoking process, and o belong to the same session as the invoking process does. Takanori's test fails even by the superuser because pid 1 belongs to a different session from curproc's one. bde POSIX now has setpgrp(), but it is quite different from setpgid() :-(. Not sure if this is what you mean, but setpgrp(2) of Solaris is somewhat like setpgid(0, 0). Spaking of Solaris, the required condition of setpgid(2) in Solaris is a little bit more strict than that in FreeBSD. Solaris prohibits the grandchildren of the curproc to be the target of setpgid(2), while FreeBSD allows that. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
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 that structure gets created because you're tired of losing fingers and toes to the person next to you wielding the axe. It's great that your friends are helping you clear the forest but you'd all like to be able to walk and pick up your cup of coffee at the end of the day as well. 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 which are the most popular - Selectively reinforce those patterns to improve the ability of developers to rely on the patterns An example of this might be investment of time in a rote API change: such changes are time-consuming requiring a lot of brute force source code modification. There's a strong motiviation to avoid redundant work here, but frequently the work is necessary, so it's also desirable to know that it's going to happen. A normal model here might be to look for a developer who's willing to do it, and wait for them to come back in a week or two when it's done. An unproductive tendancy is for four developers to go off, and do the work over two weeks, and all discover they've done it at the end. This can be avoided by making an attempt to coordinate. On a small scale and for individual cases, the problem here can be lived with. When it's in the context of a larger piece of work, it can be highly counter-productive. One reinforcement that could be made is to encourage developers to indicate what works in progress they have going, and to encourage other developers interested in a change to give that list a skim to see if someone else has already started on it, and if someone has but appears to be timing out, to encourage them to talk to the developer who has claimed it (in some sense) to find out what is going on. We are always going to have first past the post problems. If someone comes along and has rewritten a whole subsystem, and testing and performance measurement show that it's an order of magnitude better (faster, smaller, etc.) than what we have we'd be idiots not to take it, right? Obviously. But the contentious cases often aren't the ones where that's the case. The question is What processes do we need to put in place to make a project of this size and dynamisticity work? I put forward a few of them. I suggest we start somewhere (including airing gripes people have with the current system) and write down (i.e. build a web page, use TWiki) what we're going to do about it. I hate to make this analogy but we need a constitution or something like it. Not so grandiose of course, but a written set of rules and are easy to interpret that can take care of the 80% case. The 20% we'll always get to argue over but I'd rather not argue over the 100%. I think we're in the same boat here. You believe that process can help streamline the development process, and be used to help avoid the disagreements we've run into recently (assuming I read you correctly :-). I think so too. I agree we can't bring too much process--that won't work for a large number of reasons. But a little bit of process can go a long way. In particular, I'm looking for a little bit of process that will help address the perceived problems of the current situation. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
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 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.
- IMO startup scripts should be system specific
- 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 the -w switch in order to set a sysctl. This means
that we need a conditional in the script every time we set
a sysctl.
- We use different switches to startup the same daemon
- Who volunteers to test/coordinate/merge changes with the
NetBSD people?
- Each project is going to have scripts that the other project
won't use. This means someone has to invest the time and
effort to maintain scripts the project won't be using
- IMO all the conditionals are just going to obfuscate the
scripts and make them that much harder to debug
I have have followed Gordon's lead with his original patch and tried to
integrate the patch set into the base system. There's a knob in rc.conf
to use the new rc or the old one. In order to make it useable, even
while it's in development, I have organized the rc script so that when
it finishes processing the files in /etc/rc.d it continues the
current-style script where the last rc.d script left off. I've broken
the patch into 3 separate diffs to make it easier to see the changes.
Instructions:
http://home.pacbell.net/makonnen/rcng.tar.gz
unpack the tarball
cd /usr/src
patch {path to rc.d.diff}
patch {path to etc.diff}
patch {path to sbin.diff}
cd sbin/rcorder
make depend
make
make install
mergemaster -is # The -s switch is important
add rc_ng=YES to your /etc/rc.conf
I know everyone has their own idea for what the system should look like,
but I hope the work done already will help lighten the load. If you
choose not to base the final system on this I would still be willing to
contribute to whatever you decide to go with.
cheers,
mike makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 yet to see this, running either: freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Feb 28 07:41:32 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 (SMP build machine) or g1-7(5.0-C)[1] uname -a FreeBSD g1-7.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #85: Thu Feb 28 08:31:56 PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W i386 (laptop) with sources updated as of: freebeast(5.0-C)[2] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Mon Feb 25 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Feb 25 03:53:57 PST 2002 CVSup begin from cvsup14.freebsd.org at Mon Feb 25 10:01:00 PST 2002 CVSup ended from cvsup14.freebsd.org at Mon Feb 25 10:07:56 PST 2002 CVSup begin from cvsup14.freebsd.org at Tue Feb 26 03:47:03 PST 2002 CVSup ended from cvsup14.freebsd.org at Tue Feb 26 03:53:30 PST 2002 CVSup begin from cvsup14.freebsd.org at Wed Feb 27 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Wed Feb 27 03:53:38 PST 2002 CVSup begin from cvsup14.freebsd.org at Thu Feb 28 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Feb 28 03:53:56 PST 2002 Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
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 the -w switch in order to set a sysctl. This means that we need a conditional in the script every time we set a sysctl. - We use different switches to startup the same daemon - Who volunteers to test/coordinate/merge changes with the NetBSD people? - Each project is going to have scripts that the other project won't use. This means someone has to invest the time and effort to maintain scripts the project won't be using - IMO all the conditionals are just going to obfuscate the scripts and make them that much harder to debug You could handle most of this using something like: rc.bsd: # Normalize difference between BSD's # # This is the FreeBSD version # SYSCTL_W=sysctl FOOARGS=-t -U # Normalize difference between BSD's # # This is the NetBSD version # SYSCTL_W=sysctl -w FOOARGS-u rc.foo: # sysctls $SYSCTL_W xxx=yyy foo $FOOARGS /var/run/foo.pid ... Don't worry about this; it's a future thing, if ever, I think. I just wanted to throw it out there as a possible approach to solving the problem. I know everyone has their own idea for what the system should look like, but I hope the work done already will help lighten the load. If you choose not to base the final system on this I would still be willing to contribute to whatever you decide to go with. Yes, but the person who does the work is always the ultimate arbiter of how it gets done. One of my professors was fond of reformulating Occam's Razoer as Anything that works is better than anything that doesn't. Again, thanks for the hard work! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
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 is that we can work with the NetBSD guys to maybe change the NetBSD framework such that it works better for *both* systems. It is totally stupid to not share as much of the existing body of work with NetBSD. If you have ever had to administrate or use more than one Unix OS, you know how gratuitously different things are in them. Typically for no good reason. As a first pass, what should be worked toward is to add conditionals, etc. so that it becomes obvious where it would be benefital to change or abstract things. - 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 the -w switch in order to set a sysctl. This means that we need a conditional in the script every time we set a sysctl. Or just use the -w switch for now. It still works fine. Everyone wants to remove it for astetic reason. We can tolerate the looks of -w, trust me. - We use different switches to startup the same daemon Then maybe those should be put into a the defaults file. Again, part of what we should be doing is seeing what needs to be abstracted more and feed patches back to NetBSD. - Who volunteers to test/coordinate/merge changes with the NetBSD people? Me. A number of Core team members were also on board to do this. - Each project is going to have scripts that the other project won't use. This means someone has to invest the time and effort to maintain scripts the project won't be using I know we will not have 100% identical implementations. But people seem to want to use the NetBSD bits as reference but change things to how the should have been done. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
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 which are the most popular - Selectively reinforce those patterns to improve the ability of developers to rely on the patterns This sounds fine to me but we're going to have to write it down somewhere and then discuss it. This tossing ideas in the ether is not going to work because to refer back to earlier points we have to either have huge emails with everyone's comments in them, or constantly be reading the archives. So, please, if you think this is important write down your findings/current beliefs somewhere (I think TWiki or something like it is perfect for this) and let everyone comment and modify them until we have an understanding. Then lets figure out what structure we need and write that down as well. Think of it as a FreeBSD constitution if you must, only much more lightweight. You're obviously taking the lead here and that's fine, every project (and this discussion is really a project) needs a leader. I think we're in the same boat here. You believe that process can help streamline the development process, and be used to help avoid the disagreements we've run into recently (assuming I read you correctly :-). I think so too. I agree we can't bring too much process--that won't work for a large number of reasons. But a little bit of process can go a long way. In particular, I'm looking for a little bit of process that will help address the perceived problems of the current situation. Yes, you read me correctly. My mantra is, Write it down. :-) Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
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 productive and parallel development efforts, not to mention which are the most popular - Selectively reinforce those patterns to improve the ability of developers to rely on the patterns This sounds fine to me but we're going to have to write it down somewhere and then discuss it. This tossing ideas in the ether is not going to work because to refer back to earlier points we have to either have huge emails with everyone's comments in them, or constantly be reading the archives. So, please, if you think this is important write down your findings/current beliefs somewhere (I think TWiki or something like it is perfect for this) and let everyone comment and modify them until we have an understanding. Then lets figure out what structure we need and write that down as well. Think of it as a FreeBSD constitution if you must, only much more lightweight. You're obviously taking the lead here and that's fine, every project (and this discussion is really a project) needs a leader. 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 assumption that locks are advisory, but plan to write up a strawman sometime in the next week or so. Probably the process forward there will be to run the first pass by the core team for some immediate feedback regarding the strength of the recommendations, and whether it meets our goals concerning addressing the problems that have been discussed. Then I'll spit a copy out for more general comments. Yes, you read me correctly. My mantra is, Write it down. Something I've had in mind all along. BTW, your writings are much appreciated -- I hope to make the developer summit notes available in the next couple of days (I'm currently at an Apple-hosted security conference through Friday, when I'll get a chance to sit down with it over the weekend). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Updated ATAPI/CAM patches
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 one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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.. (having looked at it I think it seems fine.) So here's my vote for a quick commit. On Thu, 28 Feb 2002, Thomas Quinot wrote: 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 one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. So here's my vote for a quick commit. No. See below. There are still problems with it. It probably also needs to be reviewed before it goes in. But yes, it is a good idea. On Thu, 28 Feb 2002, Thomas Quinot wrote: 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 one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 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 the design before we hardcode too many assumptions about the implementation into the interface. You have pointed out some issues with the current interface which are valid and I would like to address those, however, there are still changes to the MI implementation that need to go in once it doesn't crash right and left. If you wish I could commit the code and make current a living hell for everyone, but my ethics don't permit me to test code that I know is broken. You know john, I wish you would commit more often and let it break things occasionally. It's REALLY HARD for anyone else to comment and help if you keep doing on P4 which is NOT the project Souce control system. Even with cvsup assistanace, it's just no-where near as convenient as having it checked in. And after you HAVE checked it in, others can help find and fix problems.. as it is you are on your own. (This is the reason I will shortly check in the KSE diffs on a branch) *sigh* Preemptive kernels don't even make it out of single user mode for SMP machines, ok? We aren't talking minor breakage here, we are talking _extreme_ breakage. If people want to play with it, preempt.patch on freefall is updated via a cron job every half hour or so. Unfortunately, however, it's in a limbo atm due to KSE and needing to sort out how the priorities are going to work. It will really be better to let KSE settle into the scheduler first adn then add preemption to the scheduler itself afterwards. The reason I'm not pushing preemption into the tree fully (I've already committed half of the original patch) is that there is other work (proc locking for example) that gets us more bang for the buck. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 time for you to fix, test, and commit it? I would REALLY like to commit my critical_*() stuff, and for the record this will also include the stage-2 stuff described in the original commit comments that will be made a few days after the current commit. -Matt Matthew Dillon [EMAIL PROTECTED] : : Preemptive kernels don't even make it out of single user mode for SMP machines, : ok? We aren't talking minor breakage here, we are talking _extreme_ breakage. : If people want to play with it, preempt.patch on freefall is updated via a cron : job every half hour or so. Unfortunately, however, it's in a limbo atm due to : KSE and needing to sort out how the priorities are going to work. It will : really be better to let KSE settle into the scheduler first adn then add : preemption to the scheduler itself afterwards. : : The reason I'm not pushing preemption into the tree fully (I've already : committed half of the original patch) is that there is other work (proc locking : for example) that gets us more bang for the buck. : : -- : : John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ : Power Users Use the Power to Serve! - http://www.FreeBSD.org/ : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb product identified as ugen
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 lun -1 (xpt0)
I notice also that usbdevs changed output from:
# usbdevs -v -d
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x), \
VIA(0x), rev 1.00
uhub0
port 1 powered
port 2 addr 2: full speed, power 400 mA, config 1, \
product 0x07d1(0x07d1), ScanLogic(0x04ce), rev 1.05
ugen0
to:
# usbdevs -d -v
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x), \
VIA(0x), rev 1.00
uhub0
port 1 powered
port 2 addr 2: full speed, self powered, config 1, \
USB to IDE(0x0002), USB to IDE(0x04ce), rev 2.60
umass0
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 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 nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. So here's my vote for a quick commit. No. See below. There are still problems with it. It probably also needs to be reviewed before it goes in. Well you are one of the main CAM peopel.. we are relying on you and Soeren. But yes, it is a good idea. On Thu, 28 Feb 2002, Thomas Quinot wrote: 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 one known pending issue with this code: on *some* machines, patched kernels hang at boot time, immediately after registering the new CAM sim. If it hangs on your machine and you can provide a backtrace of the point where the freeze occurs, it would be most helpful. Enjoy, Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 peopel.. we are relying on you and Soeren. Hmm, let me try that line of logic for a moment: I think we should have an Amdahl 6600 port of FreeBSD and we should commit it right now. [...] Well, you (Julian) you seem to have nothing to do.. we are relying on you and some other random people we can think of. Sounds weird, doesn't it ? I don't know what axe you are grinding Julian, but if you are not the one to do the work, I don't think you are in a position to ask for commit it now and have it fixed in situ. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 issues getting it to work and helping users that has problems with it. I have more than enough to do already, getting X mails extra a day asking why app XX doesn't work with drive YY is not what I'm looking for. I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. 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 minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 the patch were intrusive to the ATA drivers but its not. FWIW, I'll volunteer as a tester. I need this functionality. I've applied the patch to -stable and used it extensively with not even the slightest hint of problems. I'd offer to help maintain it, but a) I'm not a committer, b) I don't think I have the time right now, and c) I'm not familiar enough with ATA/ATAPI, CAM, or the patches to be an effective maintainer. Not to mention it's not my code. :-) -- Christopher Nielsen - Metal-wielding pyro techie [EMAIL PROTECTED] Those who are willing to trade freedom for security deserve neither freedom nor security. --Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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's new amd non intrusive so it wouldn't break anything except itself. It's functionalityu that we've wanted for a long time but haven't had. Now it's handed to us on a plate and somehow you don't like that? On Thu, 28 Feb 2002, Poul-Henning Kamp wrote: 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 peopel.. we are relying on you and Soeren. Hmm, let me try that line of logic for a moment: I think we should have an Amdahl 6600 port of FreeBSD and we should commit it right now. [...] Well, you (Julian) you seem to have nothing to do.. we are relying on you and some other random people we can think of. Sounds weird, doesn't it ? No, Have some KSE suggestions? or some for a fully working correct DEVFS (unlike the one we have now)? let me know.. I don't know what axe you are grinding Julian, but if you are not the one to do the work, I don't think you are in a position to ask for commit it now and have it fixed in situ. Poul, I've reviewed it and find it ok. The only reason to have the ATA reviewer look at it is because he is just that: teh ATA maintainer. It's a low risk commit. what axe are you grinding? Since you have nothing whatsoever to add? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) What functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 mail, the problem is not the patches as much as it is all the issues getting it to work and helping users that has problems with it. I have more than enough to do already, getting X mails extra a day asking why app XX doesn't work with drive YY is not what I'm looking for. I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. 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 minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) -Søren I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 commandline switches :-) 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... What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. If it has so many problems... why not just clean it up? Just curious... Fine by me, but do you also volounteer the time and expertise to do that ? This is the usual case of we want it all but noone is willing to invest the time and energy to keep it floating. I'll state it again, I have no problem with having ATAPI being available through CAM, I'll even do the initial commit to ensure integration is done in a way I can live with in the ATA/ATAPI driver. But I do have a problem with what comes after that, I do *not* have the time nor motivation for keeping this working and upto date, let alone answering end user questions about what works and what doesn't. Do you guys have any idea what amount of time it takes to keep modern device drivers etc up to date on HW that gets new versions and types by the week ? I could use the hours I put into this each and every week (and have done for the past 3 years in case of the ATA/ATAPI driver mind you) for playing with my kids or take the vife for a dinner in town, so excuse me for beeing a little bit pissed when you say why not just clean it up... Now, I ask for someone with the time, the knowledge and the motivation to do the maintenance work on this when/if it gets into the sources, thats all. This is a volounteer driven project guys, you give some and then you may be getting some.. I'm getting tired of giving and only getting requests for more in return... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my Hmm, your UDF code should know nothing about the lower layers, but we've been over that already :) feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; 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... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my Hmm, your UDF code should know nothing about the lower layers, but we've been over that already :) Yes, and hopefully the filesystem won't have to care, but tools like newfs_udf will. feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; 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 volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 and children to play with, so having duplicated functionality like this just ensures that too many of us are sacrificing our free time instead of working together to get a clean solution. I will go on record right now and as I've said before, there are changes that are needed in CAM land in order for me to accept this change. Due to the growing pressure to get this stuff in, I'll work with Scott and Ken to make sure we have *the right* solution for this in the next couple of weeks. Thomas' code is a great prototype, but we need to do this right so that Soren can concentrate on making X, Y, and Z new ATA chip work, we can collaborate on making our MMC device support the best in the OpenSource world, and we all have free time left over to tend to our personal lives. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 are getting wives we need to take out to dinner and children to play with, so having duplicated functionality like this just ensures that too many of us are sacrificing our free time instead of working together to get a clean solution. I will go on record right now and as I've said before, there are changes that are needed in CAM land in order for me to accept this change. Due to the growing pressure to get this stuff in, I'll work with Scott and Ken to make sure we have *the right* solution for this in the next couple of weeks. Thomas' code is a great prototype, but we need to do this right so that Soren can concentrate on making X, Y, and Z new ATA chip work, we can collaborate on making our MMC device support the best in the OpenSource world, and we all have free time left over to tend to our personal lives. Agreed, but that means that not only CAM but also the SCSI CD driver needs to learn lots of new tricks, but if that can be done I'm all ears.. Are we done with the commit it quickly now ? :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. 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 :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 not particularly pushing for quick integration of the code into the system. Quite some review and debugging is in order, as well as some discussion with the CAM team as to how to properly handle variations in devices' command sets (the current patch intercepts and translates some SCSI commands on the fly -- this is working, but a ugly hack.) Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users I have been maintaining the patch and helping users with it since the time I first published it. It is none of my intentions to impose upon anyone else the burden of taking care of it. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays As far as I was able to determine, my patch does not prevent the use of the existing ATAPI devices. If it does break them, I'd be more than willing to make any necessary changes to remedy that. So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) What I can offer is serious commitment from a non-presently-committer. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM patches
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 Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM 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 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 Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Updated ATAPI/CAM patches
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 interfere with either the CAM system or the ATAPI system that I can see. So lately atapi_softc disapperead (o.k. has been renamed). So what to do... is the person who made the change responsible to change the affected code (maybe changing this struct causes something more than find/replace the old name) or do you want to wait for the maintainer to fix it and kernel is broken for this time. So you need a person who really want this, have time and the knowledge to do it. You cant check it in and lets see what happens. Jan On Thu, 28 Feb 2002, Jan Stocker wrote: 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 Thomas. If you include it now one depends of the other and you may get into the problem of both altering the code from the other at the same time. The (somewhat selfish) behavior to include it and give maintainership to someone else leads to a originator stopping his work or the creation of 2 parallel solutions. Isn't it better the core team (or someone else thinking (s)he's a better idea) supports Thomas and a stable and good solution is integrated later (maybe with maintainership of Thomas)? Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-scsi in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 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 commandline switches :-) What functionality is lost by this ability? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. If it has so many problems... why not just clean it up? Just curious... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
usb CPiA webcam support?
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 22:28:56 0.2 terminus /boot/kernel/kernel: ugen0: VLSI Vision Ltd. USB Camera, rev 1.00/1.60, addr 2 and usbd says: usbd: attach event at 1014935200.316808000, CPiA Camera, VLSI Vision Ltd.: vndr=0x0553 prdct=0x0002 rlse=0x0160 clss=0x subclss=0x prtcl=0x device names: ugen0 usbd: Found action 'USB device' for CPiA Camera, VLSI Vision Ltd. at ugen0 Is there a driver, or is there currently any work being done on a driver for this cam? From what I found on the web this VLSI CPiA chip is very popular in cheap webcams. I found a Linux project called 'webcam' but it is a kernel module so probably difficult to port. Thanks, Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
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 this ability? Compare the features of the ATAPI vs SCSI CD drivers.. Yes, but the way the author implements this, he's not using the scsi cd drivers... he's just using the SCSI pass interfaces. If it has so many problems... why not just clean it up? Just curious... Fine by me, but do you also volounteer the time and expertise to do that ? This is the usual case of we want it all but noone is willing to invest the time and energy to keep it floating. Well, I'd be glad to maintain it if I had 3 things... commiter status, knowledge of the ATA subsystem, and knowledge of the CAM subsystem. Right now I don't know much about any of these mainly because I havn't had time to look. I'll state it again, I have no problem with having ATAPI being available through CAM, I'll even do the initial commit to ensure integration is done in a way I can live with in the ATA/ATAPI driver. But I do have a problem with what comes after that, I do *not* have the time nor motivation for keeping this working and upto date, let alone answering end user questions about what works and what doesn't. Do you guys have any idea what amount of time it takes to keep modern device drivers etc up to date on HW that gets new versions and types by the week ? I could use the hours I put into this each and every week (and have done for the past 3 years in case of the ATA/ATAPI driver mind you) for playing with my kids or take the vife for a dinner in town, so excuse me for beeing a little bit pissed when you say why not just clean it up... Well, I didn't mean it to piss anyone off... just a question really... Now, I ask for someone with the time, the knowledge and the motivation to do the maintenance work on this when/if it gets into the sources, thats all. This is a volounteer driven project guys, you give some and then you may be getting some.. I'm getting tired of giving and only getting requests for more in return... As I've said before, I'd love to contribute to FreeBSD in anyplace that needs contributed to, I really just don't know where to start. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Build(s) broken in -Current
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 its really, really annoying to have to do so . Could the make file(s) for -Current be set back to the default of treating 'warning(s)' as warnings and not errors ?? .. Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel Build(s) broken in -Current
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 edited my hand to set the offending variable to a 'default' value, but its really, really annoying to have to do so . Could the make file(s) for -Current be set back to the default of treating 'warning(s)' as warnings and not errors ?? .. If you're going to run current, you need to read this list. The problems have largly been fixed, update your sources and read UPDATING for more info. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35532/pgp0.pgp Description: PGP signature
Re: Kernel Build(s) broken in -Current
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 process. Yes the file(s) with errors can be edited my hand to set the offending variable to a 'default' value, but its really, really annoying to have to do so . Could the make file(s) for -Current be set back to the default of treating 'warning(s)' as warnings and not errors ?? .. Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 see this, running either: I cannot reproduce this assertion failure. I'll try to get core if I got this failure next time. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
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 assumption that locks are advisory, but plan to write up a strawman sometime in the next week or so. Probably the process forward there will be to run the first pass by the core team for some immediate feedback regarding the strength of the recommendations, and whether it meets our goals concerning addressing the problems that have been discussed. Then I'll spit a copy out for more general comments. Sounds like a great plan to me. Alas I think you'll get more feedback once you have the strawman proposal, people just seem to work that way. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 reversal everytime I booted. lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 before this assertion failure. But on my environment, I got this lock order reversal everytime I booted. lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 Although I did not get the reported panic, I have also had a very similar lock order reversal reported since (at least) the -CURRENT of 22 Feb. (which as far back as I presently keep the message log). I'm skeptical that there is a significant relationship between the panic the lock order reversal. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 get lock warning just before this assertion failure. But on my environment, I got this lock order reversal everytime I booted. lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 Although I did not get the reported panic, I have also had a very similar lock order reversal reported since (at least) the -CURRENT of 22 Feb. (which as far back as I presently keep the message log). I reported that particular LOR on this list on Feb 7th. -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 supposed to wait an arbitrary period of time for you to fix, test, and commit it? I would REALLY like to commit my critical_*() stuff, and for the record this will also include the stage-2 stuff described in the original commit comments that will be made a few days after the current commit. 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 (which can be split out from critical_enter/exit now). However, at this stage I would rather avoid complex optimizations of APIs that may change in the future. There is more to be gained from locking subsystems. -Matt Matthew Dillon [EMAIL PROTECTED] : : Preemptive kernels don't even make it out of single user mode for SMP : machines, : ok? We aren't talking minor breakage here, we are talking _extreme_ : breakage. : If people want to play with it, preempt.patch on freefall is updated via a : cron : job every half hour or so. Unfortunately, however, it's in a limbo atm due : to : KSE and needing to sort out how the priorities are going to work. It will : really be better to let KSE settle into the scheduler first adn then add : preemption to the scheduler itself afterwards. : : The reason I'm not pushing preemption into the tree fully (I've already : committed half of the original patch) is that there is other work (proc : locking : for example) that gets us more bang for the buck. : : -- : : John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ : Power Users Use the Power to Serve! - http://www.FreeBSD.org/ : -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Assertion faild at kern_mutex.c
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 think I did not get lock warning just before this assertion failure. But on my environment, I got this lock order reversal everytime I booted. lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 Although I did not get the reported panic, I have also had a very similar lock order reversal reported since (at least) the -CURRENT of 22 Feb. (which as far back as I presently keep the message log). I'm skeptical that there is a significant relationship between the panic the lock order reversal. There's not. The panic is due to some process being asleep or something while holding a mutex. That reversal is a known problem that involves redoing select a bit. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
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 it, maybe I should wait a couple more days :-) You could handle most of this using something like: rc.bsd: # Normalize difference between BSD's # # This is the FreeBSD version # SYSCTL_W=sysctl FOOARGS=-t -U # Normalize difference between BSD's # # This is the NetBSD version # SYSCTL_W=sysctl -w FOOARGS-u I understand what you're saying, but my problem is with the larger issue of making the startup scripts more complex (even though the reason for introducing a new rc system is to make them simpler) when the right thing to do, IMO, is to make the rest of the system more compatible so that the startup scripts can be simpler. Yes, but the person who does the work is always the ultimate arbiter of how it gets done. One of my professors was fond of reformulating Occam's Razoer as Anything that works is better than anything that doesn't. Ha ha! I like that one. I'll have to remember it the next time I'm thinking of all those unfinished projects I have sitting in the back of my mind. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
: : :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 supposed to wait an arbitrary period : of time for you to fix, test, and commit it? : : I would REALLY like to commit my critical_*() stuff, and for the record : this will also include the stage-2 stuff described in the original commit : comments that will be made a few days after the current commit. : :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 (which can be split out from critical_enter/exit now). However, at this :stage I would rather avoid complex optimizations of APIs that may change in the :future. There is more to be gained from locking subsystems. :... :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ :Power Users Use the Power to Serve! - http://www.FreeBSD.org/ 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. I don't really care whether you are ready for 'optimizations' or not. I seem to recall that you had similar objections when I started pushing Giant into the system calls, yet that work is in hind sight an obvious enabler for other work people have been doing and committing. I decided to address a serious issue that I've had with those routines for months because you consistently refused to even entertain the notion that you may have constructed the API wrong. Frankly, I feel that these changes both optimize and properly abstract the critical_*() code. I strongly believe that the abstraction you have in there now is improper. My patches have been tested, they work, and they ARE going to be committed as soon as I am able to do so. I believe you are overstepping your bounds as a committer by attempting to scrap them and I also believe that you do not fully understand the implications of the code, because you are blinded by the notion that I am making adjustments to your API. But I do, BDE does, Julian does, as do others. To me these changes are essential, and they must go in now before even more hacks are committed to the codebase to get around existing limitations. There are already hacks in the trampoline/fork_exit and ast code that seriously pollutes the MD/MI boundry, all of which you've flicked off your shoulder and explained away as being allowed by your API, and Peter added a third hack with his pmap commit (which got backed-out when he backed out the commit). These hacks make it crystal clear to me that you critical_*()/cpu_critical*() API is seriously flawed. I am addressing the issue and cleaning up the hacks to create a proper MD/MI separation of the code. It makes no sense whatsoever to me to be told not to commit something due to stale code that may not be quite compatible sitting in P4 that you can't make work in any reasonable time frame. You should stop trying to screw over my work and instead look to your own. You have so many balls in the air constructed in a fine mesh that you can't seem to accept a single change to your perfectly meshing subsystems, half of which are going stale in P4. This is greatly restricting your ability to consider deviation. I will repeat, if you want to discuss specific technical issues related to these commits after I put them in, I am all ears. I will repeat, I see nothing in this code that prevents you from accomplishing anything that you've brought up to date (which so far as just been the non-working preemption code you have sitting in P4). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: you broke current in some weird way... etc
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 PROTECTED] :The patch initializes nbuf (and many other things) statically again. :The only losses are slight bloat of the data section and the ability :... : :%%% :Index: subr_param.c :=== :RCS file: /home/ncvs/src/sys/kern/subr_param.c,v :retrieving revision 1.52 :diff -u -2 -r1.52 subr_param.c :--- subr_param.c 6 Feb 2002 01:19:19 - 1.52 :+++ subr_param.c 23 Feb 2002 07:44:45 - :@@ -56,31 +56,27 @@ : #define HZ 100 : #endif :-#define NPROC (20 + 16 * maxusers) :... : :Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NetBSD-style rc.d Project -- What I have so far...
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 don't). These are my reasons. The point you are missing is that we can work with the NetBSD guys to maybe change the NetBSD framework such that it works better for *both* systems. It is totally stupid to not share as much of the existing body of work with NetBSD. If you have ever had to administrate or use more than one Unix OS, you know how gratuitously different things are in them. Typically for no good reason. I don't think I articulated myself very well in my email. I am not against sharing code with NetBSD and I don't like gratuitous diffs any more than the next guy, but the differences in our scripts are because of gratuitous diffs elsewhere in the system. I think it's better to eliminate the differences elsewhere in the system. Then the scripts will naturally converge, with less need for conditionals. The 'sysctl -w' issue is a trivial example, but let me use it again. My argument is that it is better to have NetBSD support writing to sysctls without a '-w' switch, so that the same invocation works for both OS, than to maintain a mechanism, in the startup scripts, by which to work around the issue. Let's take another example. The REQUIREMENT line in a script cannot be made conditional. It requires a modification of rcorder(8) to do so. So, if one of NetBSD's services has a requirement that we don't have, it automatically means we need two separate scripts with different REQUIREMENT lines regardless of whether the rest of the script is identical. BTW, from a quick glance at the rcorder(8) source, modifying it to eliminate this problem is not going to be a trivial task. - Each project is going to have scripts that the other project won't use. This means someone has to invest the time and effort to maintain scripts the project won't be using I know we will not have 100% identical implementations. But people seem to want to use the NetBSD bits as reference but change things to how the should have been done. Now, that I've had a bit more time to think about it, I appreciate better the point you're making. I still think it's better to make the rest of the OS more compatible, but I can understand your point. What bothered me about it initially is that it seemed you wanted 100% compatibility and _all_ of it directed at making our startup process conform to NetBSD's. The reason I eschewed making the scripts NetBSD compatible is because once I saw how Gordon did it and I actually started converting the scripts I gained a better appreciation for the amount of work it entailed. It's going to be a tedious and long process probably, but I can see the merits now if the NetBSD people are willing to work with us. For example, I prefer our method of mounting local and then remote file systems, rather than having the sysadmin specify critical_filesystems in rc.conf ( I can already imagine the flood of emails to freebsd-questions: Help! My system won't boot... :-). Can I make a few suggestions: - Aim for at least a six month shake-down, with rc_ng=YES by default, in -Current before 5.0-Release. - A. Leave the current scripts as they are, for the moment. As new scripts get converted make them NetBSD compatible. Then work on making the initial scripts converge. This option will probably take some time. or B. Leave the current scripts as they are, for the moment. Get the scripts converted as quickly as possible. If possible make them NetBSD compatible from the start, but the overriding factor is getting the new system up and running in -Current so that people can start using it while the larger and slower task of converging the scripts goes on in parallel. Getting the rest of the rc system converted should only take a couple of weeks. - It may be useful to fix _some_ compatibility problems in the base system, even if just to reduce the complexity of a script. However, I have a suspicion we would just get bogged down in flame-fests between the two projects over who's implementation is better :( - I think on some things, the two projects may agree to disagree on, which means the majority of the code base will probably be 'identical', but there will be differences in things like, boot order, requirements, etc. I am of the opinion that it would be better to just get the system up and running to start with, and then work toward making them as identical as possible as we move forward. Never the
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 (which can be split out from critical_enter/exit now). However, at this :stage I would rather avoid complex optimizations of APIs that may change in the :future. There is more to be gained from locking subsystems. :... :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ :Power Users Use the Power to Serve! - http://www.FreeBSD.org/ 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 first people to not show up for the SMPng work whereas 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 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
: :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 first people to not show up for the SMPng work whereas :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 working full time and unable to contribute, somehow this disqualifies me now? Sorry, that doesn't hold water. In fact at the yahoo meeting oh so long ago I even said, quite clearly, that I was not going to have time in the near future. And, indeed, I did not. But I do now. While I have great respect for the work John has done, his word is most certainly NOT final in even the most generous consideration of his position. There is absolutely nothing in the charter or rules that give John authority over dozens of core source files in sys/, there is nothing that gives him veto power over anything in the source tree, and there is nothing that allows him to lock-up so many files for such a long period of time. It just isn't there so, frankly, your assertion is pretty damn hollow Poul. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
extended attribute files sizes
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 option when creating the backing file) to see if acl's would work. I am aware of the security implications of this, but my only goal was to test them out. The size of the backing file when used with -p and 388 bytes is too large of an overhead for me to live with anyhow. I am curious about the file sizes displayed in 'ls -l' for these sparse backing files. The sparse files are indeed small. Unfortunately I see strange results with 'ls -l'. An example... /usr/home/.attribute/system ls -l total 49 -rw--- 1 root wheel 544094812 Feb 28 23:13 posix1e.acl_access -rw--- 1 root wheel 12 Feb 28 23:05 posix1e.acl_default /usr/home/.attribute/system du -h 50K. /usr/home/.attribute/system 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). Galen Sampson __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: extended attribute files sizes
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 holes in files on the UFS. So you can have 1Gb file with 2 bytes put at the end of it, which would held only 1-4Kb of space. This is not extend attributes code specific. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
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 rather hollow, considering that you were :one of the first people to not show up for the SMPng work whereas :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 working full time and unable to contribute, somehow this disqualifies me now? No, but it does make you, like the rest of us, underlings to John architectural direction. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
: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 working full time and unable to contribute, somehow this disqualifies me now? No, but it does make you, like the rest of us, underlings to John architectural direction. Just a quick note that the core team is still having a lively discussion about this issue. All options are still on the table, including appointing an offical SMPng architect/manager. Please be patient. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
