Re: Popen and EVFILT_WRITE question
On Tuesday 01 April 2008 12:14:08 Dag-Erling Smørgrav wrote: > Mel <[EMAIL PROTECTED]> writes: > > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > > it will either read input or it won't, and what happens when it > > > reads depends entirely on what the fd it reads from is connected to, > > > whether it's a slow or fast device, blocking or non-blocking, etc. > > > > The kernel knows that the fd at the end of the pipe is blocked for > > reading. > > I'm not sure what you mean by that; do you mean that it's sleeping in > read() or similar? What if it uses select(), poll() or kqueue() > instead? I was hoping the fd had some property "I'm blocked for reading". > > Does it also know it's the end of a pipe and what's on the other end? > > Cause it would be a cool filter to have, if you could detect a blocked > > child as a parent. It sure is better then arbitrary timeouts (this code > > will run 'make install' as a daemon(3) and write 'yes' on those nasty > > post-install questions in ports). > > Many ports will simply use the default configuration instead of asking > if you build them with -DBATCH. Yeah, but that part is in the foreground, cause I don't want default values, I want to be able to configure the ports and it's dependencies and then build everything in the background (make config-recursive is flawed by design, that's why I started building this). Looks like BATCH is a good idea though. Thanks for making me look at that again! -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
On Tue, Apr 01, 2008 at 10:24:44AM -0700, Patrick Dung wrote: > > I think Gvinum more like software raid then LVM (allocate/resize > Logical Volume on the fly). vinum *is* a (logical) volume manager. You don't have to use RAID at all, but it's easy enough to do. Resize is currently broken, but lulf@ I think was working on that. There are many things I don't like about LVM at all, particularly in the naming and how impossible it is to setup a root mirror at install (or even mirror whole disks). -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pfind() and the proc structure
On Tue, 1 Apr 2008 07:23:58 -0700, "Rao, Nikhil" <[EMAIL PROTECTED]> wrote:
> Ok, I should have caught that :-( Another question - Now that the
> PROC_LOCK on p is obtained the all_proc lock is released and the
> function returns, at this point can't the proc get deallocated ?
>
> Nikhil
>
> 242 struct proc *
> 243 pfind(pid)
> 244 register pid_t pid;
> 245 {
> 246 register struct proc *p;
> 247
> 248 sx_slock(&allproc_lock);
> 249 LIST_FOREACH(p, PIDHASH(pid), p_hash)
> 250 if (p->p_pid == pid) {
> 251 if (p->p_state == PRS_NEW) {
> 252 p = NULL;
> 253 break;
> 254 }
> 255 PROC_LOCK(p);
> 256 break;
> 257 }
> 258 sx_sunlock(&allproc_lock);
> 259 return (p);
> 260 }
Not until you unlock the specific proc entry. You are holding a lock
for the specific proc entry, so anyone trying to `reap' the process
would have to wait until you are done with what you are doing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
--- Eygene Ryabinkin <[EMAIL PROTECTED]> wrote: > Patrick, good day. > > Mon, Mar 31, 2008 at 11:18:56AM -0700, Patrick Dung wrote: > > 4. LVM and file systems > > > > As of FreeBSD 7.0, ZFS is ported. > > This is great as FreeBSD do not have LVM in the past. > > FreeBSD has gvinum since approximately 5.x and vinum since rather > old days (3.0). Is something wrong with these LVMs? > -- > Eygene > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > I think Gvinum more like software raid then LVM (allocate/resize Logical Volume on the fly). BTW, I found a project about LVM2 on FreeBSD: http://romain.blogreen.org/Projects/FreeBSD_LVM2 Regards Patrick You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
Patrick, good day. Mon, Mar 31, 2008 at 11:18:56AM -0700, Patrick Dung wrote: > 4. LVM and file systems > > As of FreeBSD 7.0, ZFS is ported. > This is great as FreeBSD do not have LVM in the past. FreeBSD has gvinum since approximately 5.x and vinum since rather old days (3.0). Is something wrong with these LVMs? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
On 01/04/2008, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Tue, 01 Apr 2008 15:00:05 +0200 Ivan Voras <[EMAIL PROTECTED]> wrote: > > > > > > Why OpenLDAP? Why not one of the other ldap implementations available > > > in the ports? In particular, do any of them already have plugins for > > > use with pam? > > > > What are the other LDAP implementations in ports? Especially the ones > > that are actively maintained (which excludes tinyldap)? Any compliant > > LDAP server with proper schemas will "support" PAM. > > Why does it need to be actively maintained? After all, if we're going > to pull it into the base system, we'll have to find someone to > actively maintain the code in the base system. If no one is > maintaining the code externally, that in some ways makes their job > easier. Because history shows that even currently supported software (bind, sendmail, gcc) are hard to maintain :) It would take a person to pick up actively maintaining a software if its practically dead before even thinking of putting it in base. (Though those things could happen simultaneously - someone picking it up and putting it in base, the probability is very low). > And I didn't say "support", I said "already have plugins". Sure, > anything can be connected to PAM if you can get someone to write the > plugins. Or are you saying there's already an ldap plugin that uses > ldap schemas? Yes. I've been using pam_ldap and nss_ldap soon after they were available on FreeBSD (i.e. somewhere in the 5.x lifecycle). These support any LDAP server that has proper schemas (think of "LDAP schema" as a struct in C or a SQL table structure...). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
On Tue, 01 Apr 2008 15:00:05 +0200 Ivan Voras <[EMAIL PROTECTED]> wrote: > > > Why OpenLDAP? Why not one of the other ldap implementations available > > in the ports? In particular, do any of them already have plugins for > > use with pam? > > What are the other LDAP implementations in ports? Especially the ones > that are actively maintained (which excludes tinyldap)? Any compliant > LDAP server with proper schemas will "support" PAM. Why does it need to be actively maintained? After all, if we're going to pull it into the base system, we'll have to find someone to actively maintain the code in the base system. If no one is maintaining the code externally, that in some ways makes their job easier. And I didn't say "support", I said "already have plugins". Sure, anything can be connected to PAM if you can get someone to write the plugins. Or are you saying there's already an ldap plugin that uses ldap schemas? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pfind() and the proc structure
On Tue, Apr 01, 2008 at 07:23:58AM -0700, Rao, Nikhil wrote: > > Ok, I should have caught that :-( Another question - > Now that the PROC_LOCK on p is obtained the all_proc lock is released > and the function returns, at this point can't the proc get deallocated ? well.. thats why you hold the proc lock, isnt it? :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: pfind() and the proc structure
Ok, I should have caught that :-( Another question -
Now that the PROC_LOCK on p is obtained the all_proc lock is released
and the function returns, at this point can't the proc get deallocated ?
Nikhil
242 struct proc *
243 pfind(pid)
244 register pid_t pid;
245 {
246 register struct proc *p;
247
248 sx_slock(&allproc_lock);
249 LIST_FOREACH(p, PIDHASH(pid), p_hash)
250 if (p->p_pid == pid) {
251 if (p->p_state == PRS_NEW) {
252 p = NULL;
253 break;
254 }
255 PROC_LOCK(p);
256 break;
257 }
258 sx_sunlock(&allproc_lock);
259 return (p);
260 }
-Original Message-
From: Roman Divacky [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 12:56 AM
To: Rao, Nikhil
Cc: freebsd-hackers@freebsd.org
Subject: Re: pfind() and the proc structure
On Mon, Mar 31, 2008 at 11:03:31PM -0700, Rao, Nikhil wrote:
> Hi List,
>
> The pfind(..) (in kern_proc.c) function below returns the proc
structure
> for the PID passed in
>
> Say the thread that calls pfind() gets blocked at PROC_LOCK(p) (line
255
> below), in the meantime what prevents the process from exiting and
> deallocating the proc structure ? Maybe I am missing something simple
or
> the answer requires knowledge of the mutex implementation.
thats what the allproc_lock is there for
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
--- Mike Meyer <[EMAIL PROTECTED]> wrote: > On Mon, 31 Mar 2008 11:18:56 -0700 (PDT) > Patrick Dung <[EMAIL PROTECTED]> wrote: > > > 3. Support LDAP SSO out of the box > > > > Linux/Solaris/AIX have native LDAP SSO support. > > I have asked about this feature before. > > > > The problem is whether it should integrate OpenLDAP to base system. > > Why OpenLDAP? Why not one of the other ldap implementations available > in the ports? In particular, do any of them already have plugins for > use with pam? > OpenLDAP, nss_ldap, pam_ldap should be the stable. It was around for years and most Linux distro come with it. For Solaris, it comes with Sun Microsystems implementation of LDAP library. > > BTW, I see ISC Bind, Sendmail and Amd automounter is in base. > > Yes, but you're asking to move a major chunk of functionality into > the > base from ports. That doesn't really happen very often, for lots of > good reasons. Those reasons are often used to suggest that the > packages you just named be moved *out* of the base system, but that's > not much easier than moving things into it. > > The other issue is - well, how much use is this for ports? After all, > most of the servers you're going to install come from ports, so if > they don't play here, then there's not much of a win. In the past, in my University. There are several computer labs. They run around 200 Solaris and Linux workstations. I guess the total number of students in the faculty is around a thousand. Of course LDAP SSO comes into play. > > > 4. LVM and file systems > > As of FreeBSD 7.0, ZFS is ported. > > This is great as FreeBSD do not have LVM in the past. > > True, there's no "volume manager" per se. On the other hand, most of > the functionality provided by a volume manager is available through > the geom system. Frankly, geom is a lot saner than the volume > managers > I've dealt with. > > > I am sure there is still room for improvement. > > For example: ZFS/UFS shrink support, native file system journaling. > > Um, is something wrong with gjournal? Or for that matter, soft > updates > (which solve the same problem that journaling does, only with lower > overhead)? > > FreeBSD is an open source, volunteer driven project. A list of "nice > to haves" is cool for your personal use, but if you want to actually > make any of them happen, then you're the best person to do > that. Either start coding yourself, or convince somebody else to do > it > (and you'll find cash offers work fairly well). Even then, it may not > make it into the base system. Being available as a port is often > considered sufficient, or it may be that your changes aren't > considered appropriate for some other reason, like duplicating > functionality that already exists. > >-- > Mike Meyer <[EMAIL PROTECTED]> > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more > information. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > Special deal for Yahoo! users & friends - No Cost. Get a month of Blockbuster Total Access now http://tc.deals.yahoo.com/tc/blockbuster/text3.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
> Why OpenLDAP? Why not one of the other ldap implementations available > in the ports? In particular, do any of them already have plugins for > use with pam? What are the other LDAP implementations in ports? Especially the ones that are actively maintained (which excludes tinyldap)? Any compliant LDAP server with proper schemas will "support" PAM. signature.asc Description: OpenPGP digital signature
Re: Feature request
--- Mohacsi Janos <[EMAIL PROTECTED]> wrote: > > > > On Mon, 31 Mar 2008, Patrick Dung wrote: > > > Hello > > > > I have some suggestions about improving FreeBSD in some of the > > areas/features. Let's discuss. > > > > 1. Cluster capability > > > > As I know, there is: > > - Linux HA heartbeart in ports > > - LVS (Linux Virtual Server for load balancing) for FreeBSD 5.3 in > > http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm > > - SunGrid in ports. > > > > But looks like there is no native FreeBSD clustering/load balancing > > tools to do it in 'a FreeBSD way'. > > There is *BSD way of doing loadbalancing with pf. A big plus is the > pf > supports IPv6, while LVS does not. > Yes, I missed the 'sticky-address' feature of pf which can do the stick session. And we have pf CRAP to do the HA. > > > > > > 2. Networking support > > > > As we know FreeBSD has a good history/reputation on networking. > > FreeBSD lacks these support: > > > > a) MPLS > > For MPLS, Linux has project working since around in 2001. > > It is called mpls-linux in Sourceforge. > > There was a project to port Ayame to NetBSD 4.0 current, but I > don't > > know about the outcome. > > > > b) NAT-T on IPSEC > > I see NAT-T patch for FreeBSD 6 in 2005 but the patch not in > > RELEASE/CURRENT. > > > > As I know, there maybe patent infringement for NAT-T. > > But I see NetBSD 3.0 (with warning) and Linux has NAT-T support out > of > > the box. > > http://netbsd.gw.com/cgi-bin/man-cgi?ipsec++NetBSD-3.0 > > > > c) multiple default gateways > > Looks like FreeBSD do not support metrics in 'route'. > > > This is sometime missing. OpenBSD has good support for it - maybe can > be > ported from OpenBSD. > > > > > > 3. Support LDAP SSO out of the box > > > > Linux/Solaris/AIX have native LDAP SSO support. > > > > I have asked about this feature before. > > The problem is whether it should integrate OpenLDAP to base system. > > BTW, I see ISC Bind, Sendmail and Amd automounter is in base. > > > > unfortunately you have to use the ports for this > > > > 4. LVM and file systems > > > > As of FreeBSD 7.0, ZFS is ported. > > This is great as FreeBSD do not have LVM in the past. > > I am sure there is still room for improvement. > > For example: ZFS/UFS shrink support, native file system journaling. > > > > Regards > > Patrick > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and > Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > > > > > > > > > > > No Cost - Get a month of Blockbuster Total Access now. Sweet deal > for Yahoo! users and friends. > > http://tc.deals.yahoo.com/tc/blockbuster/text1.com > > ___ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > > Regards Patrick OMG, Sweet deal for Yahoo! users/friends:Get A Month of Blockbuster Total Access, No Cost. W00t http://tc.deals.yahoo.com/tc/blockbuster/text2.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Popen and EVFILT_WRITE question
Mel <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > > it will either read input or it won't, and what happens when it > > reads depends entirely on what the fd it reads from is connected to, > > whether it's a slow or fast device, blocking or non-blocking, etc. > The kernel knows that the fd at the end of the pipe is blocked for > reading. I'm not sure what you mean by that; do you mean that it's sleeping in read() or similar? What if it uses select(), poll() or kqueue() instead? > Does it also know it's the end of a pipe and what's on the other end? Cause > it would be a cool filter to have, if you could detect a blocked child as a > parent. It sure is better then arbitrary timeouts (this code will run 'make > install' as a daemon(3) and write 'yes' on those nasty post-install questions > in ports). Many ports will simply use the default configuration instead of asking if you build them with -DBATCH. Those that don't should be fixed, unless there is a very good reason (such as asking the user to accept a license before installing). You could also ask somebody in portmgr@ how the package-building cluster deals with this. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pfind() and the proc structure
On Mon, Mar 31, 2008 at 11:03:31PM -0700, Rao, Nikhil wrote: > Hi List, > > The pfind(..) (in kern_proc.c) function below returns the proc structure > for the PID passed in > > Say the thread that calls pfind() gets blocked at PROC_LOCK(p) (line 255 > below), in the meantime what prevents the process from exiting and > deallocating the proc structure ? Maybe I am missing something simple or > the answer requires knowledge of the mutex implementation. thats what the allproc_lock is there for ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
