Re: gpart is junk
Am 28.09.12 11:31, schrieb Steffen Daode Nurpmeso: > Wojciech Puchar wrote: > > |>> but still not anywhere as readable as bsdlabel. > |>> > |> > |> I did specifically say 'machine readable'. The XML is well-formed, > |XML is stupid. everything you can do with XML can be better described > |using "ancient" style text format > > Or, if all fails, YAML-is-JSON, which is much easier and cheaper > to parse (than ML), but still a well-defined standard and, in > comparison, human readable. These days I use Lua with its nice table-definition syntax for config files in many programs. Of course sandboxed, and with most functions turned off in the sandbox. The files are very readable, but of course you pay the price on including the Lua interpreter (although it's small). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Providing a default graphical environment on FreeBSD
Am 17.09.12 17:42, schrieb Poul-Henning Kamp: > In message , Lorenzo Cogotti > writ > es: >> Hi, >> I was wondering about the possibility of FreeBSD to provide an official >> supported graphical environment. > > We already do: It's called "X11" :-) and for the fun of it: CDE has been opensourced (though "only" under the LGPL) and OpenMotif will follow shortly, also under the LGPL (and no longer that strange OpenMotif license). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: tree doesnt compile
Am 25.08.2009 um 13:23 schrieb Marc Balmer: /usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? fwiw, problem is still there after 'make clean && make kernel' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
tree doesnt compile
/usr/src/sys/modules/vesa/../../i386/isa/vesa.c: In function 'vesa_set_mode': /usr/src/sys/modules/vesa/../../i386/isa/vesa.c:1117: error: duplicate case value anyone seeing this as well or is this a local f***up ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: is there any chance to get HP blade servers supported again?
is there any chance to get HP blade servers (BL460, BL465) supported again? They used to be supported until G5, but the most recent generation doesn't work with FrreeBSD (no support for the network controllers). Does anbody have more information on this? (I asked on .hardware a few weeks ago, but got no information). We just installed FreeBSD 8.0BETA3 (i386) on two HP BL460C, quad Xeon, with HP smart Array200i and QLogic QMH2462 4Gb FC HBA and networking works. At least that's what my colleague, who is onsite, just told me on the phone. - Marc Balmer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Common interface for sensors/health monitoring
Am 23.08.2009 um 18:24 schrieb Alexander Leidinger:
On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer wrote:
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 "Aurélien Méré"
wrote:
I'm just afraid by reading your email that the situation doesn't
seem to have evolved since the discussion regarding the SoC, maybe
even more taboo, and that I'll have to keep writing my own
software and drivers to get the data I want in the future if I
want to get this data under FreeBSD.. Is it the case ?
It is not "taboo", it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff.
But maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest
some time to add stuff. I have a little script which adds 24 values
to ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics="${metrics} HD3_Temp"
HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/
{ print $10 }')" HD3_Temp_type="uint8"
HD3_Temp_unit="Celsius"
metrics="${metrics} logins"
logins_value="$(who -q | grep users | cut -d ' ' -f 4)"
logins_type="uint8"
logins_unit="Users"
metrics="${metrics} SwapIn"
SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)"
SwapIn_type="uint32"
SwapIn_unit="Units"
---snip---
I would add my script to such a wiki page, if some else is willing
to start such a page.
such a script would indeed be much nicer than a well crafted
framework for the job.
Indeed...
If someone not @FreeBSD.org wants to maintain such a page, feel
free to
register in the wiki and tell me (or another committer), I will
hand out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Go and read in the archives about it, maybe you understand why
there's not much motivation to spend spare time on such a topic.
Everyone should have the right to come back with a subject, if work is
put into it. Or is the stanza that once there has been a heated
discussion about a topic, there is no possibility to come back to it,
maybe making it better a seccond time? And no, I have no plans to do
so... I am just a bit astonished about the attitude...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Common interface for sensors/health monitoring
Am 23.08.2009 um 17:08 schrieb Alexander Leidinger:
On Sat, 22 Aug 2009 21:02:32 +0200 "Aurélien Méré"
wrote:
I'm just afraid by reading your email that the situation doesn't seem
to have evolved since the discussion regarding the SoC, maybe even
more taboo, and that I'll have to keep writing my own software and
drivers to get the data I want in the future if I want to get this
data under FreeBSD.. Is it the case ?
It is not "taboo", it is just that nobody wants to spend his spare
time
with something like this now.
And yes, as far as I know you have to keep writting our own stuff. But
maybe we can set up a wiki page where people can share their
FreeBSD specific stuff. Someone just has to be willing to invest some
time to add stuff. I have a little script which adds 24 values to
ganglia, and it's extensible (4 lines for wach value), e.g.:
---snip---
metrics="${metrics} HD3_Temp"
HD3_Temp_value="$(smartctl -A ad3 |awk '/Temperature_Celsius/ { print
$10 }')" HD3_Temp_type="uint8"
HD3_Temp_unit="Celsius"
metrics="${metrics} logins"
logins_value="$(who -q | grep users | cut -d ' ' -f 4)"
logins_type="uint8"
logins_unit="Users"
metrics="${metrics} SwapIn"
SwapIn_value="$(sysctl vm.stats.vm.v_swapin | cut -d ' ' -f 2)"
SwapIn_type="uint32"
SwapIn_unit="Units"
---snip---
I would add my script to such a wiki page, if some else is willing to
start such a page.
such a script would indeed be much nicer than a well crafted framework
for the job.
If someone not @FreeBSD.org wants to maintain such a page, feel free
to
register in the wiki and tell me (or another committer), I will hand
out
write permission then.
I hope people spend their time on thinking what was bad with the
sensor framework last time and improve on that, instead.
Bye,
Alexander.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 18:29 schrieb Alexander Leidinger: On Sat, 22 Aug 2009 08:50:23 +0200 Marc Balmer wrote: The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had This assumes the kernel is monitoring the device periodically (in the general case, as there are a lot of dump sensors which do not send events on their own). The framework as in the SoC did not provide this feature to keep the kernel part simple. You want to see a value, you poll the kernel for it, and the userland would have been responsible to fire up an event. For smart sensors which trigger an event on their own (interrupt), you can use the exiting kernel event framework (and the idea in the SoC was to use it for such sensors). The devd is the userland side of it. not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... The event stuff is in the kernel, go ahead and write a driver for your smart sensor which fires events on its own. Well, most of the sensors are likely I2C or 1-Wire devices and these can only be polled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Common interface for sensors/health monitoring
Am 22.08.2009 um 08:03 schrieb Gonzalo Nemmi: On Fri, Aug 21, 2009 at 11:17 PM, Oliver Pinter wrote: Hello! When I good know, no common interface exisit in current freebsd kernel, but some other sysctl interfece exisit: coretemp, aiboost ... ~> sysctl dev.coretemp dev.coretemp.0.%desc: CPU On-Die Thermal Sensors dev.coretemp.0.%driver: coretemp dev.coretemp.0.%parent: cpu0 dev.coretemp.1.%desc: CPU On-Die Thermal Sensors dev.coretemp.1.%driver: coretemp dev.coretemp.1.%parent: cpu1 dev.coretemp.2.%desc: CPU On-Die Thermal Sensors dev.coretemp.2.%driver: coretemp dev.coretemp.2.%parent: cpu2 dev.coretemp.3.%desc: CPU On-Die Thermal Sensors dev.coretemp.3.%driver: coretemp dev.coretemp.3.%parent: cpu3 ~> sysctl dev.acpi_aiboost dev.acpi_aiboost.0.%desc: ASUStek AIBOOSTER dev.acpi_aiboost.0.%driver: acpi_aiboost dev.acpi_aiboost.0.%location: handle=\_SB_.PCI0.SBRG.ASOC dev.acpi_aiboost.0.%pnpinfo: _HID=ATK0110 _UID=16843024 dev.acpi_aiboost.0.%parent: acpi0 dev.acpi_aiboost.0.temp0: 190 dev.acpi_aiboost.0.temp1: 300 dev.acpi_aiboost.0.volt0: 1144 dev.acpi_aiboost.0.volt1: 3328 dev.acpi_aiboost.0.volt2: 5064 dev.acpi_aiboost.0.volt3: 12096 dev.acpi_aiboost.0.fan0: 1962 dev.acpi_aiboost.0.fan1: 1180 dev.acpi_aiboost.0.fan2: 1278 dev.acpi_aiboost.0.fan3: 0 dev.acpi_aiboost.0.fan4: 0 but no common if.. Is there an acpi_dell or something like that? On 8/22/09, Aurélien Méré wrote: Hi, I've been using FreeBSD for years in all my servers, but I'm facing a big problem today. All servers are under monitoring using a couple of applications and scripts. Monitored items for each server especially are CPU/mobo/UPS/HDD temperatures, CPU load, memory use, fans speed, PSU/UPS voltages, HDD/RAID status&usage, network connectivity, UPS load, battery status & runtime, ... My concern today, excepted that there is no way to gather all the data through a unique interface and that consequently we have to change the scripts depending on hardware, is that some information are no longer available at all, especially concerning the MB IC, ie. temperatures, voltages & fan speed. Actually, some SMBus controllers (like from 2006 or so) are not supported by any driver and I didn't find any port updated to access the IC directly (if even possible). Currently, I sometimes have to use mbmon with direct I/O, sometimes mbmon with SMBus, sometimes healthd and sometimes nothing works (PR 137668 or 136762 as examples in my case). Besides that, I was quite surprised that these information are available in OpenBSD through a very simple and unique sysctl interface, with up-to-date drivers, working on all my servers with a generic install. I know that below this presentation layer, this may be much less perfect, and by digging in, I found that a 2007 GSoC project for porting the OpenBSD sensor framework was realised and planned to be put in HEAD. I also read hundreds of mails concerning this project, and why finally it was not commited. As developer, I fully understand some of the concerns in these threads and that there are probably lots of things to change and work on, integrate it in a cleaner repository like snmp or whatever; and I'd be glad to help in any possible way to improve this. But in the meantime, as netadmin, this kind of information can be very important to prevent or diagnose major problems; so I'd like to know what is being planned/done on this subject, as I didn't find any more information related to this than a discussion during bsdcan 2008. Thanks for your help and time, Aurélien +10 I was looking for the same info a time ago .. something that would allow me to gather all the info from the same place, but the only thing I came up with was the very same discussion about the sensors framework port and nothing else. Any info on any such proyect will be greatly apreciated The OpenBSD sensors framework lacks some desireable features, e.g. event capabilities like getting an event if a certain threshold is exceeded. And it propbably was used for things that it better had not (yes, I am culprit for on of these (ab)uses...). I am sure these features could be added if only the code was in the tree to hack on... - Marc Balmer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: syslog() reentrant when compiling with -pthread?
Am 06.10.2004 um 16:48 schrieb Dan Nelson: The only unsafe part is openlog(), so set that up before you start any threads and you'll be okay. Once the log fd is opened, the syslog() call looks to be thread-safe. Everything in there is done with local variables and atomic writes. At least on OpenBSD I can use "%m" in the syslog() format string. This results in a call to strerror(), which is not thread safe, AFAIK. This probably is true for FreeBSD as well, so we have the following three conditions for thread safe syslog(): 1) openlog() must be called before any threads that use syslog() are started. 2) The first argument to openlog() must not be NULL. 3) The "%m" Format String must not be used in syslog() calls. Any comments? - Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
syslog() reentrant when compiling with -pthread?
Hi I am a long time Unix developer but new with FreeBSD. I worked the last years mostly with OpenBSD. First I am overwhelmed by the number of mailing lists you guys provide. Second I am not sure if I picked the right one ;-) So please direct me to the right place if this list is only for discussion of FreeBSD system development... My question regarding thread-safeness of syslog(): On OpenBSD I used syslog_r() to do thread safe logging (the software in question is a sendmail milter, which runs multithreaded). FreeBSD does not have these functions, but the cc man page states that compiling with "-pthread" links in the thread safe libc_r library instead of libc. As syslog() seems to part of libc on FreeBSD, is it safe to assume that syslog() is indeed thread safe on FreeBSD when compiling with the -pthread switch? Thanks, Marc Balmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
