RE: Circular log patches for syslog
-Original Message- From: Peter Wullinger [mailto:[EMAIL PROTECTED]] Subject: Re: Circular log patches for syslog Just to spoil the thread: Shouldn't things like this be available as additional package, so that the base system supplies only bas(e)ic functionality an everything else should be available as packages only? I would certainly be glad if these patches were incorporated into FreeBSD proper, just to eliminate the need to track future changes to syslogd and produce new (possibly buggy) patches. However, it is not clear that this feature is of wide enough usefulness to warrant that. Since it requires both a patch to an existing system utility and a new utility, it doesn't fit the package metaphor very well either. Hence, the patch and utility are available from my web page. I'm not sure I fully understand your concern, or the definition of basic functionality but I can certainly say that it would be tough for it to be more modular and optional than it is right now. :) From what I have learned, it is possible that this would be suited to .../src/release/picobsd/tinyware but even that seems premature right now. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Circular log patches for syslog
Hi, While working on another project, I made some patches to syslogd to support circular logfiles: http://software.wwwi.com/syslogd/ The syslogd patch includes changes to the man page to reflect the new usage. I don't know if this is useful to anyone else, but it came in handy for me on a small-footprint embedded project that couldn't afford to let logs grow unbounded. We have been using this in house without problems for awhile now. Any feedback on this would be appreciated. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Circular log patches for syslog
-Original Message- how do you decide the size of the circular log ? There's a utility included to unwind the log file into time order. It includes a command line option to create logfiles of user-defined size. http://software.wwwi.com/syslogd/clog.html Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: POSIX mutexes on FreeBSD
At 02:36 PM 2/5/2001 +0100, mouss wrote: do you mean that the "PTHREAD_PROCESS_SHARED", pthread_mutexattr_getpshared and the like do not currently work? dunno if they were there before, but they are in current. so you might want to check. _POSIX_THREAD_PROCESS_SHARED is still commented out in /usr/include/sys/unistd.h in -current, and I don't see implementations of these functions in /usr/src/lib/libc_r/uthread, so it appears at first glance that the state of -current is the same as -stable. This functionality does not appear to be implemented in either version. I don't actually run -current, so I can't say for sure. If I'm missing something, please let me know because it would save me a lot of trouble. My point was that the way it would be done seems to differ greatly between -stable and -current, based on the eventual availability of kernel mutexes to user processes. I don't know how far away the glorious future is, so I was wondering if it would be worthwhile for me to do a stopgap implementation in the mean time. If no one has ever noticed that the functionality was missing, the answer may well be "no." Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
POSIX mutexes on FreeBSD
Hi, While porting a project from Solaris to FreeBSD 4.2, I found out that the existing FreeBSD implementation of POSIX mutexes doesn't support sharing mutexes between processes. In order to get around this, I eventually did my own implementation of mutexes that works within the uthread framework and supports the PTHREAD_PROCESS_SHARED attribute. I can see that there are a lot of changes coming down the road in -current that could potentially affect this area. However, I don't have a good feel for how far it is to a future including kernel-based synchronization objects being available to user processes. If there is interest out there, and if it makes sense architecturally, I could do the work necessary to integrate my changes into the uthread code and submit it. Would that be of enough value/interest to be worth doing? Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
