Re: adding a new lib for more advanced argument parsing
In message: 20100927012936.ga32...@freebsd.org Alexander Best arun...@freebsd.org writes: : hi there, : : looking at applications such as geom (g_*), camcontrol, etc. makes one realise : that getopt(3) is clearly not suitable for handling such complex options. : camcontrol.c even contains a whole paragraph about why getopt(3) is considered : not appropriate to handle camcontrol's argument parsing requirements (that was : 1998!). : : why not do a vendor import of popt 1.16 e.g.? are there license restrictions? : or maybe some other lib... popt has an X11 license, which isn't a big deal. However, it depends on gettext, which is pure GPL. Also, POSIX has a lot to say about command line parsing, and popt doesn't quite match what POSIX has to say... Warner ___ 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: Modules and Buses
In message: 20100825105908.c8b626fd@dlink.ua Alexandr Rybalko r...@dlink.ua writes: : On Mon, 23 Aug 2010 22:12:59 -0600 (MDT) : M. Warner Losh i...@bsdimp.com wrote: : : In message: 20100819170643.38362078@dlink.ua : Alexandr Rybalko r...@dlink.ua writes: : : On Thu, 19 Aug 2010 09:18:46 -0400 : : John Baldwin j...@freebsd.org wrote: : : : : On Thursday, August 19, 2010 8:38:05 am Alexandr Rybalko wrote: : : Hi all, : : : : Can someone say, how `make` in sys/modules dir can obtain available buses. : : I try to make clean version of bfe, that can be for PCI bus or can be part : : of SoC (like BCM5354) on SSB bus. : : So for proper module building I need to know what bus interface I must build : : if_bfe_pci.c, or if_bfe_siba.c, or both? : : : : You can always include both buses. If a bus driver isn't present in the : : kernel the attachment will just never be invoked. : : : : I was afraid of such response. Now I have to rewrite siba implementation to newbus :) : : Thanks you for answer! : : In the module building system (modules built with sys/modules : Makefiles), we generally include all relevant busses. So, for i386 we : include EISA front ends for some devices, but omit that on amd64. For : siba, you'd only include it on mips, since that's the only platform : where this would be relevant (I know broadcom wireless drivers are : implemented via a pci - siba bridge, but that's a really special : case). : : Check out sys/modules/ep for an example from the mists of history.. : : Warner : : Thanks you Warner, : : I believe Broadcom wifi cards not last instance of Broadcom devices with PCI-to-SSB bridge. : Since this is modular platform that can join multiple already existence chips onto biggest chip. : And SSB is spacial case of OCP bus, who can be used not only for MIPS periphery, but ARM too. : : So I think I should implement the SSB as a full functional bus. I agree we should implement it as a full functional bus. It would save a little code to only compile on mips. There's no arm ssb implementation in the tree, and the use case on non-mips is still theoretical. On the other hand, the bus attach code is small, and so would have little impact being always in the module. So I could go either way with this, due to the limitations in our module system. Warner ___ 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: Why doesn't ppc(4) check non-ENXIO failures during probe?
In message: 201008241009.46624@freebsd.org John Baldwin j...@freebsd.org writes: : On Tuesday, August 24, 2010 12:09:45 am M. Warner Losh wrote: : In message: 201008171615.21103@freebsd.org : John Baldwin j...@freebsd.org writes: : : So more or less it's for BIOSes with ISA that doesn't feature plug : : and play (286s, 386s, some 486s?)? Just trying to fill in the gap :). : : : : Yes, it may perhaps still be useful for some x86 embedded systems, though : : it is doubtful that those would use a ppc(4) device perhaps. : : Many embedded x86 systems use ppc(4) as a DIO port. ppi attaches to : it and can be used to frob bits. : : These days, of course, almost all boards have ACPI, so that means they : get enumerated that way. Only boards that don't run windows might not : have ACPI, in which case the devices are usually enumerated via : PNPBIOS. But not always, since those boards tend to have the buggiest : BIOSes on the planet in this area. Hints are needed on a few of these : boards since nothing else will work. And they have Atom processors on : them... : : The specific code I am referring to is the code in ppc_isa_probe() that tries : to auto-identify a ppc port by poking at various I/O ports directly. It is : not enabled by default. You'd have to have a ppc hint that did not include an : I/O port for this code to be triggered I think as it only gets executed if a : ppc(4) device does not have an I/O port resource from ACPI/PnPBIOS/hints. Ah, that code... Yes, you're right... : I was mostly thinking of this in terms of ISA cards, and I doubt that even : modern embedded systems have ISA slots. :) There are still a few PC-104 boards knocking around (which is ISA in a different form-factor), but mostly people have moved PC-104+ which is really PCI or other things... Warner ___ 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: Why doesn't ppc(4) check non-ENXIO failures during probe?
In message: 201008171615.21103@freebsd.org John Baldwin j...@freebsd.org writes: : So more or less it's for BIOSes with ISA that doesn't feature plug : and play (286s, 386s, some 486s?)? Just trying to fill in the gap :). : : Yes, it may perhaps still be useful for some x86 embedded systems, though : it is doubtful that those would use a ppc(4) device perhaps. Many embedded x86 systems use ppc(4) as a DIO port. ppi attaches to it and can be used to frob bits. These days, of course, almost all boards have ACPI, so that means they get enumerated that way. Only boards that don't run windows might not have ACPI, in which case the devices are usually enumerated via PNPBIOS. But not always, since those boards tend to have the buggiest BIOSes on the planet in this area. Hints are needed on a few of these boards since nothing else will work. And they have Atom processors on them... Warner ___ 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: Modules and Buses
In message: 20100819170643.38362078@dlink.ua Alexandr Rybalko r...@dlink.ua writes: : On Thu, 19 Aug 2010 09:18:46 -0400 : John Baldwin j...@freebsd.org wrote: : : On Thursday, August 19, 2010 8:38:05 am Alexandr Rybalko wrote: : Hi all, : : Can someone say, how `make` in sys/modules dir can obtain available buses. : I try to make clean version of bfe, that can be for PCI bus or can be part : of SoC (like BCM5354) on SSB bus. : So for proper module building I need to know what bus interface I must build : if_bfe_pci.c, or if_bfe_siba.c, or both? : : You can always include both buses. If a bus driver isn't present in the : kernel the attachment will just never be invoked. : : I was afraid of such response. Now I have to rewrite siba implementation to newbus :) : Thanks you for answer! In the module building system (modules built with sys/modules Makefiles), we generally include all relevant busses. So, for i386 we include EISA front ends for some devices, but omit that on amd64. For siba, you'd only include it on mips, since that's the only platform where this would be relevant (I know broadcom wireless drivers are implemented via a pci - siba bridge, but that's a really special case). Check out sys/modules/ep for an example from the mists of history.. Warner ___ 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: Why is TUNABLE_INT discouraged?
In message: 20100808130624.gb40...@sandvine.com Ed Maste ema...@freebsd.org writes: : On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: : : 2010/8/8 Dag-Erling Sm??rgrav d...@des.no: : Garrett Cooper gcoo...@freebsd.org writes: : Dag-Erling Sm??rgrav d...@des.no writes: :Perhaps. ??I don't remember all the details; I can't find a discussion in :the list archives (other than me announcing the change in response to a :bug report), but there must have been one, either on IRC or in Karlsruhe. :In any case, I never removed TUNABLE_INT(), so... : It does matter for integers on 64-bit vs 32-bit architectures though, : right : : Not sure what you mean. ??The original issue was that someone had used : TUNABLE_INT() for something that was actually a memory address. ??I : changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean : value or something like maxprocs, an int is fine - but so is a long. : : Semantically valid but using TUNABLE_INT to hold pointers is a : developer bug, not the fault of the API, and there's nothing wrong : with int as a data type in this context. : : I agree with Ivan here. If we can't find an actual reason to : universally prefer long I'd like to remove this comment. : : As a counterpoint to the preference for long I can offer a reason to : prefer int: the same variable is often exposed by both a tunable and a : sysctls, and a sysctl using long can have 32-bit compat issues. (That : is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.) There's absolutely no reason to not use TUNABLE_INT for simple integers. Back in the deep, dark, dim past, there was no TUNABLE_*LONG. TUNABLE_INT was introduce in r77900 by peter. DES added TUNABLE_LONG in r137099, as well as adding the comment. The comment is bogus, or at least not quite specific enough. It has been routinely ignored since it was added. There's absolutely nothing wrong with TUNABLE_INT. We really should have a TUNABLE_ADDRESS for this case, although there's at least three types of address that we need to worry about: Physical Addresses, Virtual Addresses and Bus Addresses. You don't know if ULONG or LONG is the right type for an address, or if you need a quad (for example, 32-bit MIPS can address, through PTE entries, addresses beyond the 32-bit barrier, so you'd need a QUAD). I'm in favor of changing the comment to: /* * Please do not use for addresses or pointers */ Warner ___ 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: Missing files device_if.h and bus_if.h
Not quite. Make creates them... Matthew Jacob m...@feral.com writes: : config(8) creates them I believe : : line 523 of bus.h : : tries to include the following files: : : #include device_if.h : #include bus_if.h : : however, I don't see them any where in my source tree. Are these : missing or am I suppose to create them or are they built as part of : the build process and if the latter then why didn't I get a copy when : I built a custom kernel? : : Where do I get these files? Could someone please clue me in here? : : And since I am asking questions here, I see BUS_READ_IVAR used a : couple of places but can't find it's definition. Where is it defined? : : Thanks : Christopher : ___ : 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 : : : ___ : 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 : ___ 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: [PATCH] Build error with buildworld and -j1 on a memory backed /usr/obj
In message: aanlktildcwtnuicnrewdocm9hf9d1jemv4t4k-40h...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : The build for r209530 failed with a clean workspace and a clean : /usr/obj/scratch. I was building with a memory-disk backed /usr/obj. : Here's the error: : : === usr.bin/ar (depend) : lex -t /scratch/freebsd/current/usr.bin/ar/acplex.l acplex.c : yacc -d /scratch/freebsd/current/usr.bin/ar/acpyacc.y : cp y.tab.c acpyacc.c : rm -f .depend : mkdep -f .depend -a-I. -I/scratch/freebsd/current/usr.bin/ar : /scratch/freebsd/current/usr.bin/ar/ar.c acplex.c acpyacc.c : /scratch/freebsd/current/usr.bin/ar/read.c : /scratch/freebsd/current/usr.bin/ar/util.c : /scratch/freebsd/current/usr.bin/ar/write.c : /scratch/freebsd/current/usr.bin/ar/ar.c:66:21: error: archive.h: No : such file or directory : /scratch/freebsd/current/usr.bin/ar/acpyacc.y:35:21: error: archive.h: : No such file or directory : /scratch/freebsd/current/usr.bin/ar/acpyacc.y:36:27: error: : archive_entry.h: No such file or directory : /scratch/freebsd/current/usr.bin/ar/read.c:33:21: error: archive.h: No : such file or directory : /scratch/freebsd/current/usr.bin/ar/read.c:34:27: error: : archive_entry.h: No such file or directory : /scratch/freebsd/current/usr.bin/ar/write.c:34:21: error: archive.h: : No such file or directory : /scratch/freebsd/current/usr.bin/ar/write.c:35:27: error: : archive_entry.h: No such file or directory : mkdep: compile failed : *** Error code 1 : : Stop in /scratch/freebsd/current/usr.bin/ar. : *** Error code 1 : : Stop in /scratch/freebsd/current/usr.bin. : *** Error code 1 : : Stop in /scratch/freebsd/current. : *** Error code 1 : : Stop in /scratch/freebsd/current. : *** Error code 1 : : Stop in /scratch/freebsd/current. : : I think this is due to dependency issues with libarchive. I had : some changes in my p4 workspace to address the libarchive dependency : for libpkg (for work that's incoming in the next couple of months) : that Warner helped me out with, and once I applied the change things : worked. The patch is attached. This patch is contaminated with other patches. Warner ___ 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: Resolving lib build dependencies in src a non-race condition prone way?
In message: aanlktinyrgdwejv7t_vy6soujltvh4dz_zat_azva...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : - If no, what am I doing wrong? There's a script in tools that will build the _prebuild_libs. You'll need to use tools/make/make_libdeps.sh. src/lib/Makefile I tihnk is mostly obsolete, and certainly would have some issues working properly. We don't really use it in the build, at least to resolve build order dependencies. Warner ___ 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: Building kernels broken under AMD64 Releng 8
In message: g2i7d6fde3d1004261613h44c1631fj3b52fbb9bf4f7...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mon, Apr 26, 2010 at 2:54 PM, Stephen Hocking : stephen.hock...@gmail.com wrote: : Hi all, : : Am noticing the following when attempting to build a kernel: : : [r...@blurfl /usr/src]# make buildkernel : : -- : Kernel build for GENERIC started on Tue Apr 27 07:53:29 EST 2010 : -- : === GENERIC : mkdir -p /usr/obj/src/FreeBSD/STABLE/src/sys : : -- : stage 1: configuring the kernel : -- : cd /src/FreeBSD/STABLE/src/sys/amd64/conf; : PATH=/usr/obj/src/FreeBSD/STABLE/sr/tmp/legacy/usr/sbin:/usr/obj/src/FreeBSD/STABLE/src/tmp/legacy/usr/bin:/usr/ob/src/FreeBSD/STABLE/src/tmp/legacy/usr/games:/usr/obj/src/FreeBSD/STABLE/src/tm/usr/sbin:/usr/obj/src/FreeBSD/STABLE/src/tmp/usr/bin:/usr/obj/src/FreeBSD/STABE/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin : config -d /usr/obj/src/FreeSD/STABLE/src/sys/GENERIC : /src/FreeBSD/STABLE/src/sys/amd64/conf/GENERIC : ../../conf/options.amd64: Duplicate option COMPAT_FREEBSD32. : *** Error code 1 : : Stop in /src/FreeBSD/STABLE/src. : *** Error code 1 : : Stop in /src/FreeBSD/STABLE/src. : : : Any clues? I believe it's related to the COMPAT_IA32 option being : replaced (I haven't built a kernel since the beginning of the month). : : This was reported approximately a week ago and Warner (imp@) was : made aware of the problem, and fixed the issue in a later revision of : 8-STABLE I think. Please see: : http://lists.freebsd.org/pipermail/svn-src-all/2010-April/022969.html : for more details. You always have to rebuild world before rebuilding the kernel. You often can get away with not doing that, but not aways. I'm adding a safety belt to config, and that should be done soon. Warner ___ 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: Building kernels broken under AMD64 Releng 8
In message: w2n6300771b1004261651r1840032fhc705afd7d24...@mail.gmail.com Stephen Hocking stephen.hock...@gmail.com writes: : On Tue, Apr 27, 2010 at 9:19 AM, M. Warner Losh i...@bsdimp.com wrote: : In message: g2i7d6fde3d1004261613h44c1631fj3b52fbb9bf4f7...@mail.gmail.com : Garrett Cooper yanef...@gmail.com writes: : : On Mon, Apr 26, 2010 at 2:54 PM, Stephen Hocking : : stephen.hock...@gmail.com wrote: : : Hi all, : : : : Am noticing the following when attempting to build a kernel: : : : : [r...@blurfl /usr/src]# make buildkernel : : : : -- : : Kernel build for GENERIC started on Tue Apr 27 07:53:29 EST 2010 : : -- : : === GENERIC : : mkdir -p /usr/obj/src/FreeBSD/STABLE/src/sys : : : : -- : : stage 1: configuring the kernel : : -- : : cd /src/FreeBSD/STABLE/src/sys/amd64/conf; : : PATH=/usr/obj/src/FreeBSD/STABLE/sr/tmp/legacy/usr/sbin:/usr/obj/src/FreeBSD/STABLE/src/tmp/legacy/usr/bin:/usr/ob/src/FreeBSD/STABLE/src/tmp/legacy/usr/games:/usr/obj/src/FreeBSD/STABLE/src/tm/usr/sbin:/usr/obj/src/FreeBSD/STABLE/src/tmp/usr/bin:/usr/obj/src/FreeBSD/STABE/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin : : config -d /usr/obj/src/FreeSD/STABLE/src/sys/GENERIC : : /src/FreeBSD/STABLE/src/sys/amd64/conf/GENERIC : : ../../conf/options.amd64: Duplicate option COMPAT_FREEBSD32. : : *** Error code 1 : : : : Stop in /src/FreeBSD/STABLE/src. : : *** Error code 1 : : : : Stop in /src/FreeBSD/STABLE/src. : : : : : : Any clues? I believe it's related to the COMPAT_IA32 option being : : replaced (I haven't built a kernel since the beginning of the month). : : : : This was reported approximately a week ago and Warner (imp@) was : : made aware of the problem, and fixed the issue in a later revision of : : 8-STABLE I think. Please see: : : http://lists.freebsd.org/pipermail/svn-src-all/2010-April/022969.html : : for more details. : : You always have to rebuild world before rebuilding the kernel. You : often can get away with not doing that, but not aways. : : I'm adding a safety belt to config, and that should be done soon. : : : OK, thanks - wasn't immediately clear. Now, one should usually do an : installkernel prior to an installworld, in case system calls change, : is this correct? Yes. installkernel, reboot, installworld. For stable branches, the rate of new system call addition is slow, so you can sometimes get away with not doing the reboot. But when it fails, it can leave your system unbootable. Warner ___ 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: What tty changes - question on porting ltmdm and hcfmdm to FreeBSD 8
In message: 20100424102255.12d78...@ernst.jennejohn.org Gary Jennejohn gljennj...@googlemail.com writes: : On Fri, 23 Apr 2010 16:27:12 -0700 : Ted Mittelstaedt t...@mittelstaedt.us wrote: : :Setting aside the question of why do we break software that a lot of : people use : (these chips are in use on a lot of laptops) is there a document : somewhere that explains : what changes need to be made in code for this new tty setup? Or, is : there a set : of magic include files or a conversion shim library that will allow : these kinds : of programs to build without much work? : :Or is porting these drivers just so non-trivial that the only way is : to just delve into : the system manuals and delve into the driver code and try to figure out : what is : going on in each? If that's the case that's probably beyond my ability : but I'd : be happy to serve as a testbed. : : : The guy to ask about this would be Ed Schouten (ed@). AFAICR he did the new : TTY stuff. I don't know whether he reads these lists. : : AFAIK there is no easy way to fix this and there are no backwards compati- : bilty shims or magic header files. : : The fundamental problem with ltmdm is that it's a KLD and has to grovel : around in the guts of the kernel. That makes fixing it decidely non- : trivial. The fundamental reason that things changed was due to the locking of the TTY layer. These things change over time, and the old APIs made it very difficult to lock without driver visible changes. Warner ___ 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
Patch to config for compatibility
I also have a patch to config. It lets you put a line of the form
CONFIG_OLD_OPTION = CONFIG_NEW_OPTION
in the options files. This is useful when optioning are changing and
have a rather wide scope and need to be merged, as with the recent
CONFIG_FREEBSD32 option. With this merged to stable, we can rename
that without requiring config file tweaks on a stable branch.
Comments?
Warner
Index: mkoptions.c
===
--- mkoptions.c (revision 205300)
+++ mkoptions.c (working copy)
@@ -90,6 +90,17 @@
SLIST_INSERT_HEAD(opt, op, op_next);
read_options();
+ SLIST_FOREACH(op, opt, op_next) {
+ SLIST_FOREACH(ol, otab, o_next) {
+ if (eq(op-op_name, ol-o_name)
+ (ol-o_flags OL_ALIAS)) {
+ printf(Mapping option %s to %s.\n,
+ op-op_name, ol-o_file);
+ op-op_name = ol-o_file;
+ break;
+ }
+ }
+ }
SLIST_FOREACH(ol, otab, o_next)
do_option(ol-o_name);
SLIST_FOREACH(op, opt, op_next) {
@@ -120,7 +131,6 @@
int tidy;
file = tooption(name);
-
/*
* Check to see if the option was specified..
*/
@@ -284,6 +294,7 @@
struct opt_list *po;
int first = 1;
char genopt[MAXPATHLEN];
+ int flags = 0;
SLIST_INIT(otab);
(void) snprintf(fname, sizeof(fname), ../../conf/options);
@@ -293,6 +304,7 @@
return;
}
next:
+ flags = 0;
wd = get_word(fp);
if (wd == (char *)EOF) {
(void) fclose(fp);
@@ -324,6 +336,18 @@
(void) snprintf(genopt, sizeof(genopt), opt_%s.h, lower(s));
val = genopt;
free(s);
+ } else if (eq(val, =)) {
+ val = get_word(fp);
+ if (val == (char *)EOF) {
+ printf(%s: unexpected end of file\n, fname);
+ exit(1);
+ }
+ if (val == 0) {
+ printf(%s: Expected a right hand side at %s\n, fname,
+ this);
+ exit(1);
+ }
+ flags |= OL_ALIAS;
}
val = ns(val);
@@ -338,6 +362,7 @@
po = (struct opt_list *) calloc(1, sizeof *po);
po-o_name = this;
po-o_file = val;
+ po-o_flags = flags;
SLIST_INSERT_HEAD(otab, po, o_next);
goto next;
Index: config.h
===
--- config.h(revision 205300)
+++ config.h(working copy)
@@ -129,6 +129,8 @@
struct opt_list {
char *o_name;
char *o_file;
+ int o_flags;
+#define OL_ALIAS 1
SLIST_ENTRY(opt_list) o_next;
};
___
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: Patch for config utility
Quick comment: Why not set srcdir instead of inventing ksrcdir?
Warner
In message: 20100414130353.c28d5128@dlink.ua
Alexandr Rybalko r...@dlink.ua writes:
: Hi All,
:
: I made a patch for the config utility, which enables execution of config
outside of the kernel source tree.
: The main purpose is to avoid large number of configuration files for many
boards.
: I work on D-Link DIR-320 device (Broadcom BCM5354) which must have more than
4 different profiles with different kernel
: config files.
: If every device have 3-5 configs (with different hints files), every chip
have ~ 5-10 vendors (producing devices on this chip),
: every chip family have 10-20 chips (BCM5354 is a BCM4700 family), and
platform have 10-20 family's, so we get 4 files in conf
: directory of platform :)
:
:
: Index: mkoptions.c
: ===
: --- mkoptions.c (revision 206411)
: +++ mkoptions.c (working copy)
: @@ -294,7 +294,11 @@ read_options(void)
: char genopt[MAXPATHLEN];
:
: SLIST_INIT(otab);
: - (void) snprintf(fname, sizeof(fname), ../../conf/options);
: + if ( *ksrcdir != '\0' )
: + (void) snprintf(fname, sizeof(fname), %s/conf/options,
: + ksrcdir);
: + else
: + (void) snprintf(fname, sizeof(fname), ../../conf/options);
: openit:
: fp = fopen(fname, r);
: if (fp == 0) {
: @@ -306,7 +310,12 @@ next:
: (void) fclose(fp);
: if (first == 1) {
: first++;
: - (void) snprintf(fname, sizeof fname,
../../conf/options.%s, machinename);
: + if ( *ksrcdir != '\0' )
: + (void) snprintf(fname, sizeof fname,
: + %s/conf/options.%s, ksrcdir, machinename);
: + else
: + (void) snprintf(fname, sizeof fname,
: + ../../conf/options.%s, machinename);
: fp = fopen(fname, r);
: if (fp != 0)
: goto next;
: Index: main.c
: ===
: --- main.c(revision 206411)
: +++ main.c(working copy)
: @@ -72,6 +72,7 @@ static const char rcsid[] =
:
: char * PREFIX;
: char destdir[MAXPATHLEN];
: +char ksrcdir[MAXPATHLEN];
: char srcdir[MAXPATHLEN];
:
: int debugging;
: @@ -110,8 +111,9 @@ main(int argc, char **argv)
: char xxx[MAXPATHLEN];
: char *kernfile;
:
: + *ksrcdir = '\0';
: kernfile = NULL;
: - while ((ch = getopt(argc, argv, Cd:gpVx:)) != -1)
: + while ((ch = getopt(argc, argv, Cd:gk:pVx:)) != -1)
: switch (ch) {
: case 'C':
: filebased = 1;
: @@ -125,6 +127,12 @@ main(int argc, char **argv)
: case 'g':
: debugging++;
: break;
: + case 'k':
: + if (*ksrcdir == '\0')
: + strlcpy(ksrcdir, optarg, sizeof(ksrcdir));
: + else
: + errx(EXIT_FAILURE, Kernel ksrcdir already
set);
: + break;
: case 'p':
: profiling++;
: break;
: @@ -164,7 +172,8 @@ main(int argc, char **argv)
: len = strlen(destdir);
: while (len 1 destdir[len - 1] == '/')
: destdir[--len] = '\0';
: - get_srcdir();
: + if (*ksrcdir == '\0')
: + get_srcdir();
: } else {
: strlcpy(destdir, CDIR, sizeof(destdir));
: strlcat(destdir, PREFIX, sizeof(destdir));
: @@ -210,11 +219,14 @@ main(int argc, char **argv)
:* for sys (to make genassym.c work along with #include sys/xxx)
:* and similarly for machine.
:*/
: - if (*srcdir == '\0')
: - (void)snprintf(xxx, sizeof(xxx), ../../include);
: - else
: + if (*ksrcdir != '\0')
: (void)snprintf(xxx, sizeof(xxx), %s/%s/include,
: + ksrcdir, machinename);
: + else if (*srcdir != '\0')
: + (void)snprintf(xxx, sizeof(xxx), %s/%s/include,
: srcdir, machinename);
: + else
: + (void)snprintf(xxx, sizeof(xxx), ../../include);
: (void) unlink(path(machine));
: (void) symlink(xxx, path(machine));
: if (strcmp(machinename, machinearch) != 0) {
: @@ -222,12 +234,15 @@ main(int argc, char **argv)
:* make symbolic links in compilation directory for
:* machinearch, if it is different than machinename.
:*/
: - if (*srcdir == '\0')
: + if (*ksrcdir != '\0')
: + (void)snprintf(xxx, sizeof(xxx), %s/%s/include,
: +
Re: GEOM_ULZMA
In message: 20100304102158.ga8...@nobby.geeknest.org Ulf Lilleengen l...@pvv.ntnu.no writes: : On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote: : Hi, : I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in connection with this is an issue best left lzma : code in the file geom_ulzma.c or store lzma library separately. If separately, then where better? : : Maybe in future make lzma and gzip library kernel interface for embedded? : Then in one instance of code, userland can use compression via kernel. : : : What are the cons against combining uzip/ulzma into a geom_z/geom_compress : module that can support different compression schemes? I think this makes : more sense than having different geom modules for each compression scheme. Pros are it is easier to configure. Cons are it uses more memory and the code fights against the normal layering and abstraction by implementing things in two forks. Which one wins should likely be decided on size since this is for an embedded environment. Warner ___ 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: Help troubleshooting...
In message: 200910260959.20772.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: : M. Warner Losh wrote: : I have a usb stick (8GB) on it. This stick has about 5GB of junk on : it at this point. : : I tried to do 'cat * /dev/null' recently, to measure how fast it : goes. It got about 1GB into the drive and then I got device missing : messages. : : So devfs thinks the device went missing: : : Warner-san, maybe it is caused by the hardware problem on the USB flash : memory. Some chip on the memory might have too much heat when you access : the memory at fast rate. Then it stops working. : : : What happens if you read from two USB disks at the same time? I know that the august 25th version failed badly when I tried to burn DVDs from a USB drive to a USB attached DVD burner. This used to work flawlessly. : If the device went missing the USB HUB signalled that. This is maybe an : indication that the USB firmware on the device crashed. Maybe this is due to : heat, or unhandled race conditions when the load goes high. This same flash drive will do 20MB sustained on windows without a glitch using similar commands. : Try using dd and vary the block size from 512 to 65536 bytes. Does it stop : working with all block sizes over time? Once I get the message I posted, it is lights out for da0. No further access to the drive works at all. Warner ___ 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: Help troubleshooting...
In message: 200910261258.08135.hsela...@c2i.net Hans Petter Selasky hsela...@c2i.net writes: : On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: : I know that the august 25th version failed badly when I tried to burn : DVDs from a USB drive to a USB attached DVD burner. This used to work : flawlessly. : : Hi, : : There has been a recent fix to the EHCI driver, which might affect Mass : Storage when short transfers are used. : : Also someone else has pointed out that certain VIA chipsets have an IRQ bug : requiring the need for a software callout to restart the EHCI interrupt : handler. This is not yet patched, hence I don't know if this is a real issue. : : http://svn.freebsd.org/viewvc/base?view=revisionrevision=197682 : : Is your code from after 1st of October? This code is from: FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 so it would have r197682 baked in (the first number in my rev string is a mystery to me). Re another post: This is a 8GB flash, so I'm sure that there's enough power. Looking at the dmesg, this happend the second or third time I'd plugged in this flash drive. Here's a partial dmesg for usb things: CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1994.21-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20f42 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x1LAHF real memory = 2147483648 (2048 MB) avail memory = 2059546624 (1964 MB) ACPI APIC Table: PTLTD APIC MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 2.1 irqs 0-23 on motherboard ... pcib2: ACPI PCI-PCI bridge at device 5.0 on pci0 pci2: ACPI PCI bus on pcib2 ohci0: ATI SB400 USB Controller mem 0xc000-0xcfff irq 19 at device 19.0 on pci0 Activate PA 0xc000 at VA 0xff00c000 ohci0: [ITHREAD] usbus0: ATI SB400 USB Controller on ohci0 ohci1: ATI SB400 USB Controller mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 Activate PA 0xc0001000 at VA 0xff00c0001000 ohci1: [ITHREAD] usbus1: ATI SB400 USB Controller on ohci1 ehci0: ATI SB400 USB 2.0 controller mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0 Activate PA 0xc0002000 at VA 0xff00c0002000 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: ATI SB400 USB 2.0 controller on ehci0 ... Timecounter TSC frequency 1994209008 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 Status is 0x3106 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire Activate i/o 0x8014 Activate i/o 0x8015 ugen0.1: ATI at usbus0 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: ATI at usbus1 uhub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: ATI at usbus2 uhub2: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ad0: 114473MB FUJITSU MHV2120AT PL 008300A1 at ata0-master UDMA100 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered ... Root mount waiting for: usbus2 uhub2: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ad0s2a ugen0.2: Broadcom Corp at usbus0 ubt0: Broadcom Corp HP Integrated Module, class 224/1, rev 2.00/1.00, addr 2 on usbus0 usb_alloc_device:1635: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen2.2: HP at usbus2 umass0: HP v125w, class 0/0, rev 2.00/1.10, addr 2 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: HP v125w PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C) ugen2.2: HP at usbus2 (disconnected) umass0: at uhub2, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): Invalidating pack g_vfs_done():da0s1[READ(offset=5298202624, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298268160, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298333696, length=65536)]error = 6 g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6 g_vfs_done():da0s1[READ(offset=5298137088, length=65536)]error = 6 (da0:umass-sim0:0:0:0
Re: Help troubleshooting...
In message: 86skd6cmm8@ds4.des.no Dag-Erling_Smørgrav d...@des.no writes: : M. Warner Losh i...@bsdimp.com writes: : FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 : : so it would have r197682 baked in (the first number in my rev string : is a mystery to me). : : It means you have an inconsistent tree. The first number is the oldest : revision in your tree, the second is the newest, and the M means you : have local modifications. Yes. Of course I have local modifications, but none in the usb stack. But I've also done a svn update from the top of the tree multiple times and this version number persists. : Re another post: This is a 8GB flash, so I'm sure that there's enough : power. : : Non sequitur. Bigger chips draw more power. Is it plugged directly : into the computer? If not, is it plugged into a powered hub? How many : other devices are connected to the computer or hub? Not entirely. This flash has worked in this computer in the past without issues (like a year ago when we were first integrating hpsusb into the tree). This flash is plugged directly into the computer. This behavior is consistent across multiple ports on the computer (so it isn't a bad port). While this doesn't prove it isn't a power issue, the odds are stacked against it being one. If there were a way to get the internal hub to tell me how much power it can deliver, and for me to query the flash to see maximum current draws, we could see if we're close to the edge or not... Warner ___ 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: Help troubleshooting...
In message: 86aazecl00@ds4.des.no Dag-Erling_Smørgrav d...@des.no writes: : M. Warner Losh i...@bsdimp.com writes: : Yes. Of course I have local modifications, but none in the usb stack. : But I've also done a svn update from the top of the tree multiple : times and this version number persists. : : Weird. r185338 was a commit to the old USB stack. Try to run : svnversion in sys/dev/usb, and in an unrelated directory such as : sys/conf. If there's a difference, run svn stat in sys/dev/usb and see : if anything unexpected shows up. % cd sys/dev/usb % svnversion 198411M % cd ../../conf % svnversion 198411M Some more digging down this line shows that there was a dangling merge conflict in sys/i386/conf/GENERIC Warner ___ 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
Help troubleshooting...
I have a usb stick (8GB) on it. This stick has about 5GB of junk on
it at this point.
I tried to do 'cat * /dev/null' recently, to measure how fast it
goes. It got about 1GB into the drive and then I got device missing
messages.
Here's the dmesg messages:
# Plug it in
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: HP v125w PMAP Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
# mount it, etc
# run the cat command
Device da0s1 went missing before all of the data could be written to it; expect
data loss.
# get error messages
# Remove the drive
ugen2.2: HP at usbus2 (disconnected)
umass0: at uhub2, port 1, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
So devfs thinks the device went missing:
static int
devfs_fsync(struct vop_fsync_args *ap)
{
...
if (!vn_isdisk(ap-a_vp, error)) {
bo = ap-a_vp-v_bufobj;
de = ap-a_vp-v_data;
if (error == ENXIO bo-bo_dirty.bv_cnt 0) {
printf(Device %s went missing before all of the data
could be written to it; expect data loss.\n,
de-de_dirent-d_name);
...
So it thinks that it isn't a disk. vn_isdisk is return ENXIO because
either vp-v_rdev == NULL or the v_rdev-si_devsw == NULL.
So how the heck can that happen without other warnings? It appears
the only place it is set like this is in devfs_reclaim. But I'm
having trouble tracking down where *THAT* is called.
This is with the following system:
FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct
23 10:08:48 MDT 2009
i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64
Warner
___
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: Clang: now available from a SVN server near you!
In message: 20090604093831.ge48...@hoeg.nl Ed Schouten e...@80386.nl writes: : Good news everyone! ... : So far we've only done testing on amd64 and i386. A lot of ports are : probably still broken. Caveat emptor. Beware of dog. Slippery when wet. objects in mirror may be larger than they appear Do you have size or run-time performance comparisons yet? Warner ___ 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: about building the crosstools
In message: 4a15d288.3060...@telenix.org Chuck Robey chu...@telenix.org writes: : I got instructions from Warner about how to build my crosstools (the FreeBSD : ones) and after a minor startup contretemps, things began to work better. My : problem is that on doing the linking step, I'm getting a complaint that it can't : figure out how to build the /usr/cross/usr/lib/libc.a (/usr/cross being my : toolls destdir). I don't know how to fix this in the build, so I'd appreciate : any hints. I mean, it *seems* to me that these tools are meant to run on my : current host (i386), not the target (arm) so it really should already know about : my /usr/lib/libc.a (or shared version)) right? You may have some contamination. The xdev targets doesn't use /usr/cross at all. I'd blow that away entirely and try again. Warner ___ 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: C99: Suggestions for style(9)
In message: 49fd4391.9070...@gmx.de Christoph Mallon christoph.mal...@gmx.de writes: : M. Warner Losh schrieb: : In message: 49fcafa2.60...@gmx.de : Christoph Mallon christoph.mal...@gmx.de writes: : : Julian Elischer schrieb: : : Christoph Mallon wrote: : : KR code should be changed as part of related changes if possible. : : A sweep to change a whole file is probably also ok. : : changing them one at a time is probably not ok. : : : : But this is what actually is practiced. : : You still did not answer my question: Do you agree to remove the : : clause so no new old style declarations may be added? : : : : I think a new clause should be added specifying what should happen : : and replacing the old clause. : : : : This is not sensible. style(9) says right at the start that it [...] : : specifies the preferred style for kernel source files [...]. The : : preferred style would be to use ANSI function declarations - what else : : is there to say? There is no point in adding more when less is sufficient. : : Actually, in a style guide, there is a point. : : Adding language that says we're actively removing KR-style : declarations and definitions reinforces this point and explains to : people what's going on when they see this in the tree today. : : This just overcomplicates things. removing old style definitions is : not the preferred style, but using prototyped definitions is. Old : style definitions should not be added anymore, so just remove the : clause, which allows it currently. Adding even more about old style : definitions is counterproductive - I cannot support this. What to do, : when you are seeing an old style definition is clear: Don't Panic! I think you are wrong, and I think your failure to take constructive criticism is alienating a lot of people that would otherwise support at least part of what you are trying to do. I know I've had it enough. Warner ___ 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: C99: Suggestions for style(9)
In message: 49fcafa2.60...@gmx.de Christoph Mallon christoph.mal...@gmx.de writes: : Julian Elischer schrieb: : Christoph Mallon wrote: : KR code should be changed as part of related changes if possible. : A sweep to change a whole file is probably also ok. : changing them one at a time is probably not ok. : : But this is what actually is practiced. : You still did not answer my question: Do you agree to remove the : clause so no new old style declarations may be added? : : I think a new clause should be added specifying what should happen : and replacing the old clause. : : This is not sensible. style(9) says right at the start that it [...] : specifies the preferred style for kernel source files [...]. The : preferred style would be to use ANSI function declarations - what else : is there to say? There is no point in adding more when less is sufficient. Actually, in a style guide, there is a point. Adding language that says we're actively removing KR-style declarations and definitions reinforces this point and explains to people what's going on when they see this in the tree today. This would have been understandable by some folks if I'd left it at the first paragraph, but by adding the second it becomes clear the reasoning behind my post. Warner ___ 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: C99: Suggestions for style(9)
In message: 49fa8d73.6040...@gmx.de Christoph Mallon christoph.mal...@gmx.de writes: : M. Warner Losh schrieb: : In message: 20090428114754.gb89...@server.vk2pj.dyndns.org : Peter Jeremy peterjer...@optushome.com.au writes: : : Maybe using all of these changes is a bit too big change at once, but : : I'd like some of them applied to style(9). So, please consider the : : proposed changes individually and not a as a all-or-nothing package. : : : : One area you do not address is code consistency. Currently, the : : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : : compliant - ie the entire codebase is mostly written in the same : : style. Whilst you may not like it (and I don't know that anyone : : completely agrees with everything in style(9)), it does mean that : : the code is consistent. : : : : Changing style(9) in a way that is not consistent with current code : : means that either existing code must be brought into line with the : : new standard - which incurs a one-off cost - or the code base becomes : : split into old and new style - incurring an ongoing maintenance : : cost as maintainers switch between styles. Both approaches incur a : : risk of introducing new bugs. : : : : Note that I'm not saying that style(9) can never be changed, I'm just : : saying that any change _will_ incur a cost and the cost as well as : : the potential benefits need to be considered. : : This is my biggest worry about changing style(9) quickly. We don't : want needless churn in the tree for just style changes since it makes : it harder to track bug fixes into the past. : : I'm not saying that all the code has to be changed at once, but no new : code of the old style should be added. E.g. you should never use KR : declarations when adding a new function. And if you are going to make a : big change somewhere, then it is sensible to use the new style. Mixing and matching style has proven to be bad when it has been practiced in the past. At least when practiced on a sub-file level. : : [Reduce declaration scope as far as possible, initialise variables where : : they are declared, sort by name] : : : : Whilst my personal preference is for the style suggested by Christoph : : (and I generally agree with the points he makes), this is also the : : change that incurs the biggest stylistic change. This is not a change : : that can be practically retrofitted to existing code and therefore its : : implementation would result in a mixture of code styles - increasing : : the risk of bugs due to confusion as to which style was being used. I : : am not yet sure whether the benefits outweigh the costs, : : This is the biggest one, and I think it may be too soon. Also, we : : This is the reason, why I explicitly mentioned, that the proposed : changes should be examined independently. : : need to be careful on the initialization side of things because we : currently have a lot of code that looks like: : : : struct foo *fp; : struct bar *bp; : : fp = get_foo(); : if (!fp) return; : bp = fp-bp; : : this can't easily be translated to the more natural: : : struct foo *fp = get_foo(); : struct bar *bp = fp-bp; : : since really you'd want to write: : : struct foo *fp = get_foo(); : if (!fp) return; : struct bar *bp = fp-bp; : : which isn't legal in 'C'. However, we have enough where this isn't : : You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) : §6.8.2:1. In short: you can mix statements and declarations. : : the case that it should be allowed. We should separate the : initialization part of this from the scope part of this too. The : initialization part is already leaking into the code, while instances : of the scope restriction is rarer. : : Sorry, I do not understand these sentences. It's a stupid idea and I don't think we should do it. It is a bad practice to intermix statements and declarations, and I think a too radical departure from the current style. : : [Don't parenthesize return values] : : Removed, because it does not improve maintainability in any way. : : : : This change could be made and tested mechanically. But there is : : no justification for making it - stating that the existing rule : : is no better than the proposed rule is no reason to change. : : I'm fine with this. : : : [No KR declarations] : : Removed, because there is no need to use them anymore. : : : : Whilst this is a change that could be performed mechanically, there : : are some gotchas relating to type promotion (as you point out). : : The kernel already contains a mixture of ANSI KR declarations and : : style(9) recommends using ANSI. IMHO, there is no need to make this : : change until all KR code is removed from FreeBSD. : : I'm fine with this change. : : : [ Don't insert an empty line if the function has
Re: C99: Suggestions for style(9)
In message: 49fa8e88.1040...@gmx.de Christoph Mallon christoph.mal...@gmx.de writes: : M. Warner Losh schrieb: : In message: 20090430233648.ga95...@keira.kiwi-computer.com : Rick C. Petty rick-freebsd2...@kiwi-computer.com writes: : : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : : : This is the biggest one, and I think it may be too soon. Also, we : : need to be careful on the initialization side of things because we : : currently have a lot of code that looks like: : : : : : : struct foo *fp; : : struct bar *bp; : : : : fp = get_foo(); : : if (!fp) return; : : bp = fp-bp; : : : : this can't easily be translated to the more natural: : : : : struct foo *fp = get_foo(); : : struct bar *bp = fp-bp; : : : : since really you'd want to write: : : : : struct foo *fp = get_foo(); : : if (!fp) return; : : struct bar *bp = fp-bp; : : : : which isn't legal in 'C'. : : : : I thought we were talking about C99, in which case this is perfectly legal. : : I certainly use it all the time in my C99 code. : : Hmmm, looks like that was added. That's ugly as C++... : : I do not think, this is ugly. On the contrary, it aids maintainability, : because it reduces the scope of variables. Also quite some variables are : only initialised and not changed afterwards, so it's nice to have the : declaration and the only assignment in a single place. IMO this is a : quite natural style, because you don't have anything in the code, before : it is needed: Get the first pointer; if something is wrong, bail out; : get the second pointer - the second pointer does not (textually) exist : before it is needed. It is ugly. Hunting for declarations sucks, and it is one of the things I really like about BSD code is that I don't have to. This is a religious point, and we're dangerously close to saying my religion is better than your religion. I don't like this part of the proposal at all. I can see the value in relaxing it for when you have a series of variables that are initialized, but relaxing it to the point where you intermix code and declarations goes way too far. It is bad enough to have to deal with inner scopes, but tolerable. It is intolerable to have to look for it anywhere in a big function. It tends to encourage spaghetti code, which is one of the things that style(9) tries to discourage in many subtle ways. Warner ___ 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: C99: Suggestions for style(9)
In message: 49fadef3.5010...@gmx.de
Christoph Mallon christoph.mal...@gmx.de writes:
: Marius Strobl schrieb:
: On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
: return with parentheses:
: Removed, because it does not improve maintainability in any way. There
: is no source for confusion here, so the rule even contradicts the rule,
: which states not to use redundant parentheses. Maybe, decades ago it was
: just a workaround for a broken compiler, which does not exist anymore.
:
: FYI, the idea behind this rule is said to be to able to use
: a macro return(), f.e. for debugging you then can do:
: #define return(x) do {
\
: printf(returning from %s with %d\n, __func__, (x)); \
: return (x); \
: } while (0)
:
: Given the this is a nifty feature and parentheses around the
: return value don't hurt maintainability in any way IMO this
: rule should stay.
:
: This is mentioned nowhere in style(9) (in general it is lacking reasons
: why something is some way or the other).
It has been an example used for the past 15 years at least as to why
to do this... I don't know how many people have actually used the
ability to do this in code.
: Also I consider this as gross abuse: Macro names shall be in all
: uppercase, so it is clear that there is a macro at work. Therefore
: return is not a candidate. So this would violate yet another rule in
: style(9) (the original return already violates the no-redundant
: parentheses rule).
: Also I would not mention __func__: there were objections against using
: it in the past (though I, logically, prefer its use).
It is a debugging aid, but one of dubious value for a far more
fundamental reason:
return;
will break any macro.
Warner
___
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: C99: Suggestions for style(9)
In message: 20090501.081229.1359784281@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 49fa8e88.1040...@gmx.de : Christoph Mallon christoph.mal...@gmx.de writes: : : M. Warner Losh schrieb: : : In message: 20090430233648.ga95...@keira.kiwi-computer.com : : Rick C. Petty rick-freebsd2...@kiwi-computer.com writes: : : : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : : : : : This is the biggest one, and I think it may be too soon. Also, we : : : need to be careful on the initialization side of things because we : : : currently have a lot of code that looks like: : : : : : : : : :struct foo *fp; : : :struct bar *bp; : : : : : :fp = get_foo(); : : :if (!fp) return; : : :bp = fp-bp; : : : : : : this can't easily be translated to the more natural: : : : : : :struct foo *fp = get_foo(); : : :struct bar *bp = fp-bp; : : : : : : since really you'd want to write: : : : : : :struct foo *fp = get_foo(); : : :if (!fp) return; : : :struct bar *bp = fp-bp; : : : : : : which isn't legal in 'C'. : : : : : : I thought we were talking about C99, in which case this is perfectly legal. : : : I certainly use it all the time in my C99 code. : : : : Hmmm, looks like that was added. That's ugly as C++... : : : : I do not think, this is ugly. On the contrary, it aids maintainability, : : because it reduces the scope of variables. Also quite some variables are : : only initialised and not changed afterwards, so it's nice to have the : : declaration and the only assignment in a single place. IMO this is a : : quite natural style, because you don't have anything in the code, before : : it is needed: Get the first pointer; if something is wrong, bail out; : : get the second pointer - the second pointer does not (textually) exist : : before it is needed. : : It is ugly. Hunting for declarations sucks, and it is one of the : things I really like about BSD code is that I don't have to. : : This is a religious point, and we're dangerously close to saying my : religion is better than your religion. I don't like this part of the : proposal at all. I can see the value in relaxing it for when you have : a series of variables that are initialized, but relaxing it to the : point where you intermix code and declarations goes way too far. It : is bad enough to have to deal with inner scopes, but tolerable. It is : intolerable to have to look for it anywhere in a big function. It : tends to encourage spaghetti code, which is one of the things that : style(9) tries to discourage in many subtle ways. This came off a little more absolute than I wanted. I should have added in the absence of hard data... Warner ___ 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: C99: Suggestions for style(9)
In message: 20090428114754.gb89...@server.vk2pj.dyndns.org Peter Jeremy peterjer...@optushome.com.au writes: : Maybe using all of these changes is a bit too big change at once, but : I'd like some of them applied to style(9). So, please consider the : proposed changes individually and not a as a all-or-nothing package. : : One area you do not address is code consistency. Currently, the : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : compliant - ie the entire codebase is mostly written in the same : style. Whilst you may not like it (and I don't know that anyone : completely agrees with everything in style(9)), it does mean that : the code is consistent. : : Changing style(9) in a way that is not consistent with current code : means that either existing code must be brought into line with the : new standard - which incurs a one-off cost - or the code base becomes : split into old and new style - incurring an ongoing maintenance : cost as maintainers switch between styles. Both approaches incur a : risk of introducing new bugs. : : Note that I'm not saying that style(9) can never be changed, I'm just : saying that any change _will_ incur a cost and the cost as well as : the potential benefits need to be considered. This is my biggest worry about changing style(9) quickly. We don't want needless churn in the tree for just style changes since it makes it harder to track bug fixes into the past. : [Reduce declaration scope as far as possible, initialise variables where : they are declared, sort by name] : : Whilst my personal preference is for the style suggested by Christoph : (and I generally agree with the points he makes), this is also the : change that incurs the biggest stylistic change. This is not a change : that can be practically retrofitted to existing code and therefore its : implementation would result in a mixture of code styles - increasing : the risk of bugs due to confusion as to which style was being used. I : am not yet sure whether the benefits outweigh the costs, This is the biggest one, and I think it may be too soon. Also, we need to be careful on the initialization side of things because we currently have a lot of code that looks like: struct foo *fp; struct bar *bp; fp = get_foo(); if (!fp) return; bp = fp-bp; this can't easily be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp-bp; since really you'd want to write: struct foo *fp = get_foo(); if (!fp) return; struct bar *bp = fp-bp; which isn't legal in 'C'. However, we have enough where this isn't the case that it should be allowed. We should separate the initialization part of this from the scope part of this too. The initialization part is already leaking into the code, while instances of the scope restriction is rarer. : [Don't parenthesize return values] : Removed, because it does not improve maintainability in any way. : : This change could be made and tested mechanically. But there is : no justification for making it - stating that the existing rule : is no better than the proposed rule is no reason to change. I'm fine with this. : [No KR declarations] : Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI KR declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all KR code is removed from FreeBSD. I'm fine with this change. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. : +.Sh LOCAL VARIABLES : : Last, but definitely not least, I added this paragraph about the use of : local variables. This is to clarify, how today's compilers handle : unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using non-primitive types or when optimisation is not enabled (though : I'm not sure if this is supported). Assuming that gcc (and icc and : clang) behaves as stated in all supported optimisation modes, this : change would appear to be quite safe to make. Agreed, in general. We don't want to optimize our code style based on what one compiler does, perhaps on x86. Warner ___ 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: C99: Suggestions for style(9)
In message: 20090430233648.ga95...@keira.kiwi-computer.com Rick C. Petty rick-freebsd2...@kiwi-computer.com writes: : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : This is the biggest one, and I think it may be too soon. Also, we : need to be careful on the initialization side of things because we : currently have a lot of code that looks like: : : : struct foo *fp; : struct bar *bp; : : fp = get_foo(); : if (!fp) return; : bp = fp-bp; : : this can't easily be translated to the more natural: : : struct foo *fp = get_foo(); : struct bar *bp = fp-bp; : : since really you'd want to write: : : struct foo *fp = get_foo(); : if (!fp) return; : struct bar *bp = fp-bp; : : which isn't legal in 'C'. : : I thought we were talking about C99, in which case this is perfectly legal. : I certainly use it all the time in my C99 code. Hmmm, looks like that was added. That's ugly as C++... : And I thought this was the point of this discussion, to be able to declare : variables when you first use them. That's one of the proposed changes, which I think is a mistake and would cause the most code churn. And it isn't one of the items that's being discussed: only moving variables into inner scopes is on the table... Warner ___ 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: Patch for MS Hyper V (virtualization)
In message: 200904061154.19601@freebsd.org John Baldwin j...@freebsd.org writes: : On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: : : Apr 4, 2009 02:10:23 PM, ivo...@freebsd.org wrote: : Can someo=ne please review and commit (if appropriate) the tweak for : Hyper-V shu=tdown issue at : http://shell.peach.ne.jp/aoyama/archives/40 : ? : : =The problem is: the VM appears to hang on shutdown without it : (hanging : the Hyper-V VM with it so the host also can't shutdown or reboot : re=liably - someone at MS skipped the part where an error in the VM : isn't=supposed to bring the host down with it) : I don't have the commit =permission any more but I can review :-) : Yes, Hyper-V does not like th=e writes into the PCI config space. Why not? We need to understand exactly what it doesn't like because this is non-standard compliant behavior. : Very specifically, : writing the base=register window address of the simulated 21140 : screws up something : tha=t prevents the VM from shutting down. Interestingly, even reading : and writi=ng : back the same value has this effect. So the patch is valid. Then the Hyper-V is broken. This is bog-standard PCI behavior. The OS must be able to write to the BARs to size the resource being decoded. In addition, the OS is allowed to move the location of an allocation for a BAR, so avoiding writes to it is bad. Finally, some BIOSes don't allocate resources for a card, and this would totally prevent 21140's from being usable on those machines. : =I don't particularly like the hackish checking for the 21140 chip, : and I'=m not sure : if if would break some real 21140 chip out there. If the dri=ver does : the same as another : one I've seen, the driver tries to align t=he register window to : 0x80, and in the : simulated 21140 it's already ali=gned. I've had a quick look but : couldn't say it : for sure. I'd do it dif=ferently: check if the value being written is : the same that was read, : =and skip the write in this case. : Let me see, maybe I'll make a dif=ferent patch. : : Hmm, the problem is we need to be able to write to BARs to size them. Any OS : needs to be able to do this to know what address space regions are being : decoded by devices. We can't avoid writing to BARs. Exactly. Not only do we have to read/write them to size the BAR resource, but as I indicated above, one must write to them when the BIOS doesn't assign resources to the BAR and the driver requests that resource. Warner ___ 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: kobj methods (DEVMETHOD) that have differing signatures (in src/sys)
In message: 4989e87b.5010...@icyb.net.ua Andriy Gapon a...@icyb.net.ua writes: : : This based on the (much) earlier proposal described here: : http://lists.freebsd.org/pipermail/freebsd-arch/2008-April/007982.html : : The patch was applied to the recent current sources and LINT kernels for : all architectures that have LINT/NOTES (i.e. arm excluded) were built. : : Here's a link to the list of files and line numbers where KOBJ methods : are set with functions that have differing signatures: : http://www.icyb.net.ua/~avg/kobj_method_sigs.txt : : List of the most common issues can be found at the first link. : : Hope this is useful. This is very helpful. I'll work through the low-hanging fruit. If others want to work as well, please ping me. Warner ___ 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: KLD: program.ko: depends of kernel - no avaiable
In message: ed8027db0901301124r1e742393ia5eb6f1bf8c48...@mail.gmail.com Jacky Oh assaulter0...@gmail.com writes: : Can the solution become the source tree updates to the same version of my : installed kernel? Sorry for my irregular-time questions and responses but : currently i cannot access to inet.. It's really difficult for me becouse I : don't put instant solution for my systems and my case of study problems...I : try to resolve the problem if the source tree is it fails.. The solution is to rebuild the kernel and the modules, install them and reboot. Warner ___ 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
Code review request: cdcontrol status label additon
Please find enclosed patches to enable printing of the ISO-9660 Volume
label, if present, for a CD. I've connected this to the 'status
label' command. Please comment.
Warner
Index: cdcontrol.1
===
--- cdcontrol.1 (revision 187760)
+++ cdcontrol.1 (working copy)
@@ -156,12 +156,14 @@
Play the right subtrack on both left and right channels.
.It Ic info
Print the table of contents.
-.It Ic status Op Cm audio | media | volume
+.It Ic status Op Cm audio | label | media | volume
Print the information about the disc:
.Pp
.Bl -tag -width .Cm volume -compact
.It Cm audio
the current playing status and position
+.It Cm label
+the current ISO 9660 volume label, if present
.It Cm media
the current media catalog status
.It Cm volume
Index: cdcontrol.c
===
--- cdcontrol.c (revision 187760)
+++ cdcontrol.c (working copy)
@@ -86,6 +86,7 @@
#define STATUS_AUDIO 0x1
#define STATUS_MEDIA 0x2
#define STATUS_VOLUME 0x4
+#define STATUS_LABEL 0x8
struct cmdtab {
int command;
@@ -801,6 +802,8 @@
what |= STATUS_MEDIA;
else if (!strncasecmp(p, volume, strlen(p)))
what |= STATUS_VOLUME;
+ else if (!strncasecmp(p, label, strlen(p)))
+ what |= STATUS_LABEL;
else {
warnx(invalid command arguments);
return 0;
@@ -851,6 +854,32 @@
else
printf (No volume level info available\n);
}
+ if (what STATUS_LABEL) {
+#defineISO9660_MAGIC \x01 CD001 \x01\x00
+#defineISO9660_OFFSET 0x8000
+#defineVOLUME_LEN 32
+#define CD_SECTOR_LEN 2048
+#define LABEL_NAME_OFF 0x28
+#define LABEL_NAME_LEN 32
+ char *sp, *ep, buffer[CD_SECTOR_LEN];
+
+ lseek(fd, ISO9660_OFFSET, SEEK_SET);
+ rc = read (fd, buffer, CD_SECTOR_LEN);
+ if (rc == CD_SECTOR_LEN
+ memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) {
+ sp = buffer + LABEL_NAME_OFF;
+ ep = sp + LABEL_NAME_LEN - 1;
+ while (*ep == ' ' ep = sp)
+ *ep-- = '\0';
+ if (verbose)
+ printf(ISO 9660 Label is: %s\n, sp);
+ else
+ printf(%s\n, sp);
+ }
+ else
+ printf(No ISO 9660 label found\n);
+ }
+
return(0);
}
___
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: Code review request: cdcontrol status label additon
In message: 87k58f7npu@kobe.laptop Giorgos Keramidas keram...@freebsd.org writes: : On Wed, 28 Jan 2009 02:09:50 -0700 (MST), M. Warner Losh i...@bsdimp.com wrote: : Please find enclosed patches to enable printing of the ISO-9660 Volume : label, if present, for a CD. I've connected this to the 'status : label' command. Please comment. : : The style looks ok, but this didn't work for a Fedora Core 10 disk I : have around. glabel on the other hand detected the label fine: : : [ /var/log/messages ] : Jan 28 11:59:00 kobe kernel: GEOM_LABEL: Label for provider acd0t01 is iso9660/F10-i686-Live. : : Running `status label' on the same disk didn't find one: : : # ./cdcontrol status label : No ISO 9660 label found : # ./cdcontrol -f /dev/acd0t01 status label : No ISO 9660 label found : : Maybe it would be better to hook into glabel (when available) or use a : userland copy of the same code? Not going to look at glabel for this. I lifted the code from glable, but must have done it badly. I'll grab a core 10 cd and see what's up. Warner ___ 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: Code review request: cdcontrol status label additon
In message: 87mydbiecp@kobe.laptop Giorgos Keramidas keram...@freebsd.org writes: : On Wed, 28 Jan 2009 09:20:46 -0700 (MST), M. Warner Losh i...@bsdimp.com wrote: : Not going to look at glabel for this. I lifted the code from glable, : but must have done it badly. I'll grab a core 10 cd and see what's up. : : It may not be Fedora specific. I just happened to have it handy... : : Sorry for creating *more* work for you. I'll see if I can hack at : cdcontrol too, and provide more useful input :) I was actually thinking of moving this from status to its own command because the label isn't the only thing from the master header that I want to display. Warner ___ 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: Code review request: cdcontrol status label additon
In message: 87d4e7e4y0@kobe.laptop
Giorgos Keramidas keram...@ceid.upatras.gr writes:
: On Wed, 28 Jan 2009 18:29:10 +0200, Giorgos Keramidas keram...@freebsd.org
wrote:
: On Wed, 28 Jan 2009 09:20:46 -0700 (MST), M. Warner Losh
i...@bsdimp.com wrote:
: Not going to look at glabel for this. I lifted the code from glable,
: but must have done it badly. I'll grab a core 10 cd and see what's up.
:
: It may not be Fedora specific. I just happened to have it handy...
:
: Sorry for creating *more* work for you. I'll see if I can hack at
: cdcontrol too, and provide more useful input :)
:
: If it helps at all, I added this:
:
: lseek(fd, ISO9660_OFFSET, SEEK_SET);
: rc = read (fd, buffer, CD_SECTOR_LEN);
: + if (rc == -1)
: + err(1, read);
: if (rc == CD_SECTOR_LEN
: memcmp(buffer, ISO9660_MAGIC, sizeof(ISO9660_MAGIC) - 1) == 0) {
:
: and it seems that read() fails with EIO:
:
: lseek(3,0x8000,SEEK_SET) = 32768 (0x8000)
: read(3,0xbfbfe3a3,2048) ERR#5 'Input/output error'
OK. That's definitely not page aligned.
: My `/var/log/messages' shows at the same time:
:
: Jan 28 19:01:52 kobe kernel: acd0: FAILURE - non aligned DMA transfer
attempted
: Jan 28 19:01:52 kobe kernel: acd0: setting up DMA failed
I have no clue what this means. I'll have to investigate.
Chances are that your hardware has limitations on where DMA can come
from and no provisions in the acd driver to bounce them (likely a
reasonable performance thing). This likely means that I'll have to
malloc the buffer to get it page aligned...
Warner
___
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: KLD: program.ko: depends of kernel - no avaiable
In message: 20090129045304.ga18...@debian.samsung.router Alexej Sokolov bsd.qu...@googlemail.com writes: : Can you paste please the dmesg after KLDloading ? Sometimes there are : in /var/log/messages more helpful information. And I would like to look : your syscall code if it possible. : : Alexej : : On Tue, Jan 20, 2009 at 05:21:02PM +0100, Jacky Oh wrote: : Hi, : : I'm writing a syscall module and he compiles well but at load time, kldload : shows: : : KLD: program.ko: depends of kernel - no avaiable : : anyone know something about this? The problem here is that the kernel _FreeBSD_version was bumped and no longer matches. Jacky installed the kernel with version, say 800060, and then updated the source bases where it changed to 800061, built modules and tried to load them. Warner ___ 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: KLD: program.ko: depends of kernel - no avaiable
In message: ed8027db0901200821g4f78beeek1d6a4b489587...@mail.gmail.com Jacky Oh assaulter0...@gmail.com writes: : Hi, : : I'm writing a syscall module and he compiles well but at load time, kldload : shows: : : KLD: program.ko: depends of kernel - no avaiable : : anyone know something about this? Yes. rebuild the kernel and modules to have the same __FreeBSD_version warner ___ 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: uart and big-endian targets
In message: 4976297c.7020...@bluezbox.com Oleksandr Tymoshenko go...@bluezbox.com writes: : Yesterday I ran into a problem with uart(4) on big-endian MIPS : board. uart code treats registers as bytes and reads/writes them using : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : have regshft in uart_bas structure. It works for little-endian flags : where lowest byte resides at uart_base + (regnum regshft) address : but for big endian targets actual data resides at : uart_base + ((regnum + 1) regshft) - 1. That's not the problem. The problem is that we're trying to do byte accesses to word registers. That's why we see a disconnect between the addresses since we're reading the wrong byte. also, we may be getting lucky with this access, but many chips have issues when you access word registers as bytes. : One way to solve it is to increase uart_base when setting uart_bas, : but it's not obvious and requires knowledge of uart(4) internals. : I think better solution would be to take into account endianess : when defining uart_regofs. Or if other BE devices have data in : highest byte new field should be added to uart_bas (defaulted to 0) : : Any thoughts? The base problem here is: uart.h: #define uart_getreg(bas, reg) \ bus_space_read_1((bas)-bst, (bas)-bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value)\ bus_space_write_1((bas)-bst, (bas)-bsh, uart_regofs(bas, reg), value) These should be, for the platform you are using: #define uart_getreg(bas, reg) \ bus_space_read_4((bas)-bst, (bas)-bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value)\ bus_space_write_4((bas)-bst, (bas)-bsh, uart_regofs(bas, reg), value) There's no easy way to swap these out, nor is there a way to have variants for different kinds of hardware attached to the same machine (the UART on the SoC will have different access patterns than the UART on the modem on the PC Card that's plugged in, for example). This is a short-coming in the design of UART. One that's relatively easy to fix, mind you, and one that could easily be fixed. There's so many twists like this that it can be hard to anticipate them all. The Octeon port basically copies uart_dev_ns8250.c and provides its own set of accessors. This is right from a accessing the hardware correctly point of view, but a pita from a code reuse point of view. Were it not for the other quirks in Cavium's serial ports, there'd be little reason to go this route... Warner ___ 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: uart and big-endian targets
In message: 20090120.133113.-1630673491@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 4976297c.7020...@bluezbox.com : Oleksandr Tymoshenko go...@bluezbox.com writes: : : Yesterday I ran into a problem with uart(4) on big-endian MIPS : : board. uart code treats registers as bytes and reads/writes them using : : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : : have regshft in uart_bas structure. It works for little-endian flags : : where lowest byte resides at uart_base + (regnum regshft) address : : but for big endian targets actual data resides at : : uart_base + ((regnum + 1) regshft) - 1. : : That's not the problem. The problem is that we're trying to do byte : accesses to word registers. That's why we see a disconnect between : the addresses since we're reading the wrong byte. also, we may be : getting lucky with this access, but many chips have issues when you : access word registers as bytes. : : : One way to solve it is to increase uart_base when setting uart_bas, : : but it's not obvious and requires knowledge of uart(4) internals. : : I think better solution would be to take into account endianess : : when defining uart_regofs. Or if other BE devices have data in : : highest byte new field should be added to uart_bas (defaulted to 0) : : : : Any thoughts? : : The base problem here is: : : uart.h: : : #define uart_getreg(bas, reg) \ : bus_space_read_1((bas)-bst, (bas)-bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value)\ : bus_space_write_1((bas)-bst, (bas)-bsh, uart_regofs(bas, reg), value) : : These should be, for the platform you are using: : : #define uart_getreg(bas, reg) \ : bus_space_read_4((bas)-bst, (bas)-bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value)\ : bus_space_write_4((bas)-bst, (bas)-bsh, uart_regofs(bas, reg), value) : : There's no easy way to swap these out, nor is there a way to have : variants for different kinds of hardware attached to the same machine : (the UART on the SoC will have different access patterns than the UART : on the modem on the PC Card that's plugged in, for example). This is : a short-coming in the design of UART. One that's relatively easy to : fix, mind you, and one that could easily be fixed. There's so many : twists like this that it can be hard to anticipate them all. : : The Octeon port basically copies uart_dev_ns8250.c and provides its : own set of accessors. This is right from a accessing the hardware : correctly point of view, but a pita from a code reuse point of view. : Were it not for the other quirks in Cavium's serial ports, there'd be : little reason to go this route... actually, the more I've thought about this, and chatted with folks offline, I think the right way to fix this is in bus_space... Warner ___ 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: 3x read to write ratio on dump/restore
In message: 20090111041710.gb5...@server.vk2pj.dyndns.org Peter Jeremy peterjer...@optushome.com.au writes: : On 2009-Jan-09 09:50:27 -0700, M. Warner Losh i...@bsdimp.com wrote: : The read kBps was 3x the write kBps. : ... : Any ideas what gives? I observed this with 16MB cache and with 32MB : cache, fwiw. : : I've seen this as well. AFAIK, this is a side-effect of dump's caching. : : My top-of-head explanation is that each dump process has its own cache : but actual I/O is round-robined on a (roughly) block scale so a large : contiguous file will wind up in each 'slave' process's cache. : : The most obvious (and easiest) fixes are to either implement a shared : cache (though this means another level of inter-process communication) : or only use a single 'slave' process when caching is enabled. I'll have to look into this... Most of the files I was backing up were large contiguous files (26 10GiB .dv files from my camera). : The cache algorithm could probably be enhanced as well - apart from : inode blocks, any block will only be accessed once so once a block has : been accessed, it can be purged from the cache (which is completely : opposite to a normal cache). Yes, read everything, purge once it is touched. Warner ___ 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
3x read to write ratio on dump/restore
I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 3231231 147549.5 0 00.0 97.5| da1s1a 0 39 0 00.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. Warner ___ 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: libusb for linux-emulation
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Martin Laabs wrote: : Hans Petter Selasky wrote: :No, you cannot use the linux libusb on FreeBSD. You need to use the FreeBSD :compiled libusb. The USB kernel interfaces are quite different. : : OK - I see. I'm just trying to build a hermaphrodite library. Compile with : linux but using the BSD ioctls. : Is there a crosscompiler to compile linux binarys from freebsd? This would : make the job much easier. : : Yes, I think you can use ports/devel/cross-gcc. I've definitely got to get my cross tools changes into head. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Daniel O'Connor wrote: : On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: : this will make system trying to bind 32-bit libs to 64-bit program. it : can't work : :rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. : : The same problem happens with the Linux run time linker - it merrily tries to : link FreeBSD libraries to Linux binaries with predictable results.. : : You *can* link Linux libraries with FreeBSD binaries (and : vice versa), if the library does not perform any syscalls, : e.g. it is a pure computation library or similar. : : That said it would be really nice if it ignored incompatible libraries :) : : No. Please don't put such pseudo-cleverness into rtld. : It wouldn't be an improvement, in fact it might break some : working configurations. Yes. I have a bunch of printer drivers that I've used that link in linux shared libraries... They are in ports... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386/127710: My driver PCI probe is not called for my correspondingdevice ID and Vendor ID
In message: [EMAIL PROTECTED] Bagavathy Kumar Mahendran [EMAIL PROTECTED] writes: : : Dear Baldwin, : Thanks for your support .but my pci probe function is not : getting called for my device id and vendor id. Because pccbb driver : already sets the device_set_desc as PCI-CardBus Bridge. So is there any : other option for me to make my_pciprobe function to be called for my : corresponding device id and vendor id. That's not why your probe isn't called. Setting a description is standard behavior for the probe routine. Are you sure that the device probe routine is getting called at all for any device? Have you tried just leaving cbb out of the kernel? I recently fixed the original problem in cbb (the fact it doesn't check the bridge type too), maybe you could try to pick up that fix as well? Warner : Thanks, : : Regards, : Bagavathy kumar .M : : : : -Original Message- : From: John Baldwin [mailto:[EMAIL PROTECTED] : Sent: Wednesday, October 01, 2008 8:57 PM : To: freebsd-hackers@freebsd.org : Cc: Bagavathy Kumar Mahendran ; Warner Losh : Subject: Re: FW: i386/127710: My driver PCI probe is not called for my : correspondingdevice ID and Vendor ID : : On Wednesday 01 October 2008 08:50:15 am Bagavathy Kumar Mahendran : wrote: : : Dear All, : Iam writing a new driver for a SAS/SATA Controller having : a : Class ID -0x01 : Sub Class - 0x07 : Programming Interface - 0x00 : : Hence instead of my probe function the Static build Card Bus Driver : cbb : is attaching just by simply checking sub class 0x07 and programming : interface 0x00.hence my probe gets failed. Kindly help me in resolving : this .what I thought is to add the card bus driver a checking of CLASS : ID in its pci probe function. : : The pccbb driver returns BUS_PROBE_DEFAULT (it should probably return : GENERIC : in the case where it matches only on class codes). Your driver just : needs to : return a numerically higher value (but still 0) to claim the device. : You : can probably use BUS_PROBE_VENDOR or BUS_PROBE_DEFAULT + 1. : : -- : John Baldwin : : DISCLAIMER: : --- : : The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. : It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in : this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. : Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of : this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have : received this email in error please delete it and notify the sender immediately. Before opening any mail and : attachments please check them for viruses and defect. : : --- : : ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of r180753: ABI problems?
In message: [EMAIL PROTECTED] Max Laier [EMAIL PROTECTED] writes: : Hi, : : I'm wondering how to merge r180753 to stable/7 as luoqi@ has indicated that he : doesn't have time to take care of it right now. : : It seems that changing the size of pcicfgregs (aka struct pcicfg) which is : part of struct pci_devinfo is out of the question, right? Ideas where to : store the HT related state or how to avoid storing the state are welcome. : : The merge result is attached for reference. This fix is essential for many : nforce based boards from ASUS which are rather common, I'm afraid. So it : would be good to have this in 7.1/6.4, I think. I think this is OK. pcicfgregs is an internal to pci implementation detail. You've added it at the end, so any leakage of the offsets won't matter. All subclasses of pci would be affected. Internal to the kernel isn't all that interesting, since they are all compiled at the same time. This would only matter for modules. Cardbus and acpi would be the only modules affected. That would mean you couldn't boot a 7.0 kernel with a 7.1 set of modules or vice versa. I'm not sure that is actually going to work anyway... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Driver accessing other drivers/devices ?
In message: [EMAIL PROTECTED] Alex Hornung [EMAIL PROTECTED] writes: : Hello, : : I need to access the hard disk from within a driver that is not a FS. : I would also need to get a list of PCI devices connected. Is there a : way I can access these devices directly, at least in the first case, : issuing directly ATA/IDE commands to the hard disk? There's always ata_if.m... : In the case of PCI it would be even nicer to be able to communicate : with the pci driver... but if that's not possible, it's also ok if I : can access the PCI bus controller directly. The driver I'm writing is : not a PCI or PCI device driver either. : : Hope someone can help me out on this one, it's important that there's : no user-space code... Generally, you don't want to scan the PCI bus to look for drivers to talk to. That's bad kharma and likely begging to be abused. Having said that, I've had cooperative drivers in the kernel before. They usually look for each other and send messages to each other with kobj. It is better to look for friend0 that you know can receive messages. kobj adds a layer of protection since it will gracefully give an error when you can't do it. Hey, wait, ata_if is kobj... You could likely expand it to allow queueing of commands and such. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sun4v arch
In message: [EMAIL PROTECTED] Pietro Cerutti [EMAIL PROTECTED] writes: : -BEGIN PGP SIGNED MESSAGE- : Hash: SHA512 : : Kris Kennaway wrote: : | Just so everyone is on the same page, what is needed to keep sun4v : | viable are people with experience with (or intention to learn about) low : | level architectural and implementation details of the FreeBSD kernel and : | the sun4v hardware platform, who know their way around things like : | pmap.c and other MD places where the kernel interfaces with the bare : | metal, and who are willing to make a long term (multi-year) commitment : | to supporting the platform. : : If we had docs... There's a bunch of sun4v docs available. See http://www.sun.com/processors/documentation.html for example. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of r180753: ABI problems?
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Saturday 23 August 2008 02:42:09 am M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : : Max Laier [EMAIL PROTECTED] writes: : : Hi, : : : : I'm wondering how to merge r180753 to stable/7 as luoqi@ has indicated : : that he doesn't have time to take care of it right now. : : : : It seems that changing the size of pcicfgregs (aka struct pcicfg) which : : is part of struct pci_devinfo is out of the question, right? Ideas where : : to store the HT related state or how to avoid storing the state are : : welcome. : : : : The merge result is attached for reference. This fix is essential for : : many nforce based boards from ASUS which are rather common, I'm afraid. : : So it would be good to have this in 7.1/6.4, I think. : : I think this is OK. : : pcicfgregs is an internal to pci implementation detail. You've added : it at the end, so any leakage of the offsets won't matter. All : subclasses of pci would be affected. Internal to the kernel isn't all : that interesting, since they are all compiled at the same time. This : would only matter for modules. Cardbus and acpi would be the only : modules affected. That would mean you couldn't boot a 7.0 kernel with : a 7.1 set of modules or vice versa. I'm not sure that is actually : going to work anyway... : : ACPI (and OFW's) PCI bus code isn't going to care, and I doubt cardbus is : either. Hmm, actually, cardbus doesn't, but ACPI actually does (acpi_pci CardBus' does because it creates a slightly larger pcicfgreg per device... : uses its own extended ivars for PCI devices to cache ACPI handles). That : said, this particular ABI was actually broken earlier by MSI (though I didn't : realize it at the time. :( ). Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openbsd solution to mounted umass removal
In message: [EMAIL PROTECTED] Andriy Gapon [EMAIL PROTECTED] writes: : : I've just came back from a good 2 week vacation and catching up on news. : In release notes for OpenBSD 4.3 I see the following: : http://openbsd.org/43.html : Filesystems on USB devices are automatically dismounted if the device is : disconnected. : : Does anybody have more [technical] details on this? effectively, that's what -current winds up doing... except for the actual umount() call... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devctl (alike?) for devfs
In message: [EMAIL PROTECTED] : However it is possible that it did something wrong - at that time I had : devctl calls in kern_conf. I'd be inclined to say 'create' and 'destroy' for the events. ATTACH and DETACH are typically reserved for device driver events, not for device node events. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: symbol table
In message: [EMAIL PROTECTED] Erik Trulsson [EMAIL PROTECTED] writes: : On Sun, Apr 20, 2008 at 11:24:32PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Erik Trulsson [EMAIL PROTECTED] writes: : : On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: : : Hi, : : : : I have a question about symbol table. : : One of the section In symbol table is memory adress which symbol is located. : : I wonder if this memory adress is bound at run-time or compile-time? : : : : It depends. Symbols referring to objects in a dynamically loaded library : : will be bound at run-time, the rest should be bound at compile-time. : : They are bound at link-time, not compile-time. This is splitting a : fine hair, but compile-time is when a .o or .so is created, while link : time combines .o-like things together into a bigger thing. : : Well, I consider linking to be part of the compilation process so for : me link-time is a subset of compile-time. : You are however completely correct that it is at link-time that the binding : happens (for those symbols that can be resolved at link-time anyway.) While you might consider them the same, these are very important differences that need to be taken into account. A compile-time constant, for example, can be used to size an automatic array. A link-time or run-time constant cannot without gcc's extensions (magic tricks can be played to make link-time constants size certain global objects, but then sizeof() those objects fail). The terminology is well worn, and matters in some contexts, so I tend to be a stickler here... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: symbol table
In message: [EMAIL PROTECTED] emily becker [EMAIL PROTECTED] writes: : Hi, : : I have a question about symbol table. : One of the section In symbol table is memory adress which symbol is located. : I wonder if this memory adress is bound at run-time or compile-time? Typically, run-time, but there are exceptions. : if it is compile-time, I don't understand how do we know whether the symbol : is located this adress. The exceptions are for things like 'start' which live at a fixed address by the ELF ABI specification for most processors. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: symbol table
In message: [EMAIL PROTECTED] Erik Trulsson [EMAIL PROTECTED] writes: : On Sun, Apr 20, 2008 at 12:02:09PM +0300, emily becker wrote: : Hi, : : I have a question about symbol table. : One of the section In symbol table is memory adress which symbol is located. : I wonder if this memory adress is bound at run-time or compile-time? : : It depends. Symbols referring to objects in a dynamically loaded library : will be bound at run-time, the rest should be bound at compile-time. They are bound at link-time, not compile-time. This is splitting a fine hair, but compile-time is when a .o or .so is created, while link time combines .o-like things together into a bigger thing. When that bigger thing is a final link, the addresses for the static portions of the binary are set. When the final thing is a dynamic library, the addresses float (since all the code is PIC anyway, they don't really matter). Dynamic parts of executables are bound at run-time. : if it is compile-time, I don't understand how do we know whether the symbol : is located this adress. : Maybe this adress is already bound by other process or like this. : : Each process runs in its own address space, and therefore the compiler : (actually: the linker) can know exactly where in this address space things : will end up. The run-time linker (ld.so) is the one that knows where things wind up in a given process... libc.so and other shared libraries can and do link at different addresses for different processes. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : The vkernel feature has certainly benefits, e.g. the fact : that you can attach to it with standard gdb and use the : familiar debugging facilities, which can attract more Can't you say qemu -s and attach gdb to that port as well? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building in /usr/src copied to $HOME
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2008-03-18 21:28, V??clav Haisman [EMAIL PROTECTED] wrote:
: Hi,
: I am trying to use /usr/src copied to my $HOME but the build process
: doesn't want to work. For example when I try build /bin/cp I get the
: following:
:
: shell::wilx:~/freebsd/src/bin/cp make
: /usr/home/users/wilx/freebsd/src/bin/cp/../Makefile.inc, line 9:
: Malformed conditional (${MK_DYNAMICROOT} == no)
: /usr/share/mk/bsd.init.mk, line 15: if-less endif
: make: fatal errors encountered -- cannot continue
:
: Is there any sort of tutorial/prescription anywhere how to use /usr/src
: tree that does not reside in /usr/src?
:
: Hmmm, that should work. I regularly build as a non-root user, at
: `/home/build/src'.
:
: The error about ``Malformed conditional'' seems a bit odd too. Are you
: using /usr/bin/make? What version of FreeBSD is the build host running,
: and what version of the source tree have you checked out?
The problem is that MK_DYNAMICROOT is defined by bsd.own.mk. This
likely means that he's not building the same version of FreeBSD as the
system is running, otherwise the system's bsd.own.mk file would cope.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Building in /usr/src copied to $HOME
In message: [EMAIL PROTECTED]
Václav Haisman [EMAIL PROTECTED] writes:
: M. Warner Losh wrote, On 21.3.2008 17:34:
: In message: [EMAIL PROTECTED]
: Giorgos Keramidas [EMAIL PROTECTED] writes:
: : On 2008-03-18 21:28, V??clav Haisman [EMAIL PROTECTED] wrote:
: : Hi,
: : I am trying to use /usr/src copied to my $HOME but the build process
: : doesn't want to work. For example when I try build /bin/cp I get the
: : following:
: :
: : shell::wilx:~/freebsd/src/bin/cp make
: : /usr/home/users/wilx/freebsd/src/bin/cp/../Makefile.inc, line 9:
: : Malformed conditional (${MK_DYNAMICROOT} == no)
: : /usr/share/mk/bsd.init.mk, line 15: if-less endif
: : make: fatal errors encountered -- cannot continue
: :
: : Is there any sort of tutorial/prescription anywhere how to use /usr/src
: : tree that does not reside in /usr/src?
: :
: : Hmmm, that should work. I regularly build as a non-root user, at
: : `/home/build/src'.
: :
: : The error about ``Malformed conditional'' seems a bit odd too. Are you
: : using /usr/bin/make? What version of FreeBSD is the build host running,
: : and what version of the source tree have you checked out?
:
: The problem is that MK_DYNAMICROOT is defined by bsd.own.mk. This
: likely means that he's not building the same version of FreeBSD as the
: system is running, otherwise the system's bsd.own.mk file would cope.
:
: Warner
: That was the problem as I stated in email from two days ago. I guess nobody
: noticed the second email :)
I noticed after I replied. That should teach me to read the whole
thread before replying :-)
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: : On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: : Solaris lacks TAILQ_xxx stuff too, so I would prefer something like : bsdcompat.h or similar. : : Seconded - linux.h is far too generic. I must say I like the idea : of being able to build *BSD on Linux machines! : : Why? What are you going to do with it? Presumable install it somewhere, : where? : : Will the differences in the end result of what is built worth the risk, : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? The end result will be the ability to build FreeBSD on a Linux host. VMware players aren't an option, and will not be contemplated as an acceptable solution. The overhead is too high, especially when explaining to people what needs to be done to deploy. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Wed, Mar 05, 2008 at 01:02:17PM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : David O'Brien [EMAIL PROTECTED] writes: : : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: : : On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: : : Solaris lacks TAILQ_xxx stuff too, so I would prefer something like : : bsdcompat.h or similar. : : : : Seconded - linux.h is far too generic. I must say I like the idea : : of being able to build *BSD on Linux machines! : : : : Why? What are you going to do with it? Presumable install it : : somewhere, where? : : : : Will the differences in the end result of what is built worth the risk, : : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? : : The end result will be the ability to build FreeBSD on a Linux host. : VMware players aren't an option, and will not be contemplated as an : acceptable solution. The overhead is too high, especially when : explaining to people what needs to be done to deploy. : : I think you're wrong about the overhead is too high... - but the proof : will be in the pudding. With installing VMware player and building : FreeBSD on FreeBSD - all the 10,000's of docs explaining to users how : to build will be valid. : : With this cross build these docs will be wrong - folks will be much more : on their own. : : Beyond the docs - I think you underestimate the amount of work getting : all the cross-tools built and installed will be. : : I guess we'll just have to wait and see. Yup. The proof will be in the pudding, as they say. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2008-03-03 22:42, M. Warner Losh [EMAIL PROTECTED] wrote:
: Greetings,
:
: here's a set of diffs that will allow FreeBSD's usr.bin/make to build
: on Linux. I'm sure they are gross, and I don't plan to commit them
: (at least not all of them), but I thought I'd post them here to see
: what people think.
:
: I think that the extra config.h includes, the errc - errx patches and
: the Makefile.dist patches may be good for the tree. The rest may not
: meet FreeBSD's source tree policies.
:
: Comments?
:
: Warner
:
: diff -ur pmake.orig/config.h pmake/config.h
: --- pmake.orig/config.h 2005-02-01 03:50:35.0 -0700
: +++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
: @@ -108,4 +108,27 @@
: # endif
: #endif
:
: +#ifndef TAILQ_HEAD_INITIALIZER
: +#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
: +#endif
: +
: +#ifndef TAILQ_FOREACH
: +#defineTAILQ_FOREACH(var, head, field)
\
: + for ((var) = TAILQ_FIRST((head)); \
: + (var); \
: + (var) = TAILQ_NEXT((var), field))
: +#endif
: +
: +#ifndef TAILQ_FIRST
: +#defineTAILQ_FIRST(head) ((head)-tqh_first)
: +#endif
: +
: +#ifndef TAILQ_NEXT
: +#defineTAILQ_NEXT(elm, field) ((elm)-field.tqe_next)
: +#endif
: +
: +#ifndef TAILQ_EMPTY
: +#defineTAILQ_EMPTY(head) ((head)-tqh_first == NULL)
: +#endif
: +
: #endif /* config_h_efe0765e */
:
: In a Solaris-based project I'm involved with, I used our own queue.h
: pretty much verbatim. Only STAILQ_LAST() seems to use __offsetof(),
: which may be a bit tricky to 'port over'.
:
: That's not to say that I don't like the above change, but I am just
: `thinking aloud' about the possibility of importing sys/queue.h into
: `http://hg.hellug.gr/bmake' to avoid the need for the #ifdef trick.
:
: The TAILQ_*() macros are pretty simple, so it's fairly easy to copy them
: verbatim. In the long run, they may get `stale' though, so a full
: import of sys/queue.h looks like a `safe' thing. It also stands a
: chance of working on Solaris, which doesn't have a sys/queue.h header
: at all.
Yea. I'm not sure the right way to cope with systems that have
sys/queue.h, but have one that isn't sufficient for our needs. I'll
fully admit that the above is a hack.
Maybe there needs to be an autoconfig-like step...
: --- pmake.orig/main.c 2007-12-18 15:58:14.0 -0700
: +++ pmake/main.c2008-03-03 22:25:47.543349000 -0700
: @@ -660,11 +664,9 @@
: int level = (value == NULL) ? 0 : atoi(value);
:
: if (level 0) {
: - errc(2, EAGAIN, Invalid value for recursion level (%d).,
: - level);
: + errx(2, Invalid value for recursion level (%d)., level);
: } else if (level MKLVL_MAXVAL) {
: - errc(2, EAGAIN, Max recursion level (%d) exceeded.,
: - MKLVL_MAXVAL);
: + errx(2, Max recursion level (%d) exceeded., MKLVL_MAXVAL);
: } else {
: char new_value[32];
: sprintf(new_value, %d, level + 1);
:
: Hohoho! I didn't realize errx() was already available on Linux. Last
: night, when I ran `man errx' there was no manpage, but I forgot that
: glibc prefers Info manuals :)
Yea. I don't even know why we do a errc, which is fairly recent bsd
invention.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED]
Robert Watson [EMAIL PROTECTED] writes:
:
: On Mon, 3 Mar 2008, M. Warner Losh wrote:
:
: --- pmake.orig/config.h 2005-02-01 03:50:35.0 -0700
: +++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
: @@ -108,4 +108,27 @@
: # endif
: #endif
:
: +#ifndef TAILQ_HEAD_INITIALIZER
: +#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
: +#endif
:
: In most ports of FreeBSD parts to Linux that I've seen, the preferred
solution
: has to been to bring the entire FreeBSD queue.h with you rather than relying
: on the native Linux queue.h. This is what we do for OpenBSM, for example;
: this also helps out when you get to Mac OS X, Solaris, etc, where all the
: queue.h's continue to vary in subtle ways. This depends a fair amount on a
: lack of header pollution in the OS's own include files, of course...
I was rather hoping for something that could be used without any of
that nonsense...
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : On Tue, 4 Mar 2008, M. Warner Losh wrote: : : : In most ports of FreeBSD parts to Linux that I've seen, the preferred solution : : has to been to bring the entire FreeBSD queue.h with you rather than relying : : on the native Linux queue.h. This is what we do for OpenBSM, for example; : : this also helps out when you get to Mac OS X, Solaris, etc, where all the : : queue.h's continue to vary in subtle ways. This depends a fair amount on a : : lack of header pollution in the OS's own include files, of course... : : I was rather hoping for something that could be used without any of that : nonsense... : : Sadly, nonsense seems to be the name of the game in software portability. : Here's the broken autoconf garbage I use to pick out adequate queue.h's from : inadequate ones: : : # sys/queue.h exists on most systems, but its capabilities vary a great deal. : # test for LIST_FIRST and TAILQ_FOREACH_SAFE, which appears to not exist in : # all of them, and are necessary for OpenBSM. : AC_TRY_LINK([ : #include sys/queue.h : ], [ : : #ifndef LIST_FIRST : #error LIST_FIRST missing : #endif : #ifndef TAILQ_FOREACH_SAFE : #error TAILQ_FOREACH_SAFE : #endif : ], [ : AC_DEFINE(HAVE_FULL_QUEUE_H,, Define if queue.h includes LIST_FIRST) : ]) : : Note that there are at least a couple of mostly stylistic bugs there (could : use compile rather than link, definition description is poor, errors are : inconsistent). :-) I found that on both Linux and Mac OS X, the queue.h's : didn't have everything I wanted. Right. But I'm not going to use autoconf. It is totally off the table as far as I'm concerned. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : (When I say 'nice' above, I mean it in the normal autoconf sense of the word : 'nice', so don't take that the wrong way!) It would be nicer if it didn't use autoconf. I hate to be a stick in the mud, but autoconf is pure evil. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2008-03-04 15:15, Robert Watson [EMAIL PROTECTED] wrote:
: On Mon, 3 Mar 2008, M. Warner Losh wrote:
: --- pmake.orig/config.h2005-02-01 03:50:35.0 -0700
: +++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
: @@ -108,4 +108,27 @@
: # endif
: #endif
:
: +#ifndef TAILQ_HEAD_INITIALIZER
: +#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
: +#endif
:
: In most ports of FreeBSD parts to Linux that I've seen, the preferred
: solution has to been to bring the entire FreeBSD queue.h with you rather
: than relying on the native Linux queue.h. This is what we do for OpenBSM,
: for example; this also helps out when you get to Mac OS X, Solaris, etc,
: where all the queue.h's continue to vary in subtle ways. This depends a
: fair amount on a lack of header pollution in the OS's own include files, of
: course...
:
: Fortunately, in Solaris where I am testing the import of sys/cdefs.h and
: sys/queue.h today, things seem to be `ok'. Just importing the two
: headers at http://hg.hellug.gr/bmake/gker/rev/68bfc25ed443 seems to have
: moved things one step closer towards building everything on Solaris:
:
: Now off to the next little annoyance. Building with Sun Studio on
: Solaris 10, in my test machine at home, stops at:
:
: arch.c, line 1063: undefined symbol: INT_MIN
: cc: acomp failed for arch.c
: *** Error code 2
: make: Fatal error: Command failed for target `arch.o'
: Current working directory /home/keramida/bmake/src
:
: This is easy to fix with:
:
: diff -r 68bfc25ed443 src/arch.c
: --- a/src/arch.cTue Mar 04 17:29:11 2008 +0200
: +++ b/src/arch.cTue Mar 04 17:35:08 2008 +0200
: @@ -96,6 +96,7 @@
:#include ctype.h
:#include errno.h
:#include inttypes.h
: +#include limits.h
:#include regex.h
:#include stdlib.h
:#include stdio.h
We likely should just commit this to FreeBSD's make, since Section
5.2.4.2.1 of the C standard says that INT_MIN is defined there.
: The next part, about the missing errx() functions on Solaris is going to
: be tonight's fun. If there are too many missing functions, it may be
: worth adding a static `libcompat' with copies of just the functions we
: need to run BSD make on non-BSD hosts.
In the longer term, this likely is a good idea. In the shorter term,
I'm not so sure that this is a good idea, since all you'd need would
be inlines for the functions that make uses.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : On 2008-03-04 15:38, Robert Watson [EMAIL PROTECTED] wrote: : On Tue, 4 Mar 2008, M. Warner Losh wrote: : : : In most ports of FreeBSD parts to Linux that I've seen, the preferred solution : : has to been to bring the entire FreeBSD queue.h with you rather than relying : : on the native Linux queue.h. This is what we do for OpenBSM, for example; : : this also helps out when you get to Mac OS X, Solaris, etc, where all the : : queue.h's continue to vary in subtle ways. This depends a fair amount on a : : lack of header pollution in the OS's own include files, of course... : : I was rather hoping for something that could be used without any of that : nonsense... : : Sadly, nonsense seems to be the name of the game in software portability. : Here's the broken autoconf garbage I use to pick out adequate queue.h's : from inadequate ones: : : # sys/queue.h exists on most systems, but its capabilities vary a great deal. : # test for LIST_FIRST and TAILQ_FOREACH_SAFE, which appears to not exist in : # all of them, and are necessary for OpenBSM. : AC_TRY_LINK([ : #include sys/queue.h : ], [ : : #ifndef LIST_FIRST : #error LIST_FIRST missing : #endif : #ifndef TAILQ_FOREACH_SAFE : #error TAILQ_FOREACH_SAFE : #endif : ], [ : AC_DEFINE(HAVE_FULL_QUEUE_H,, Define if queue.h includes LIST_FIRST) : ]) : : Note that there are at least a couple of mostly stylistic bugs there (could : use compile rather than link, definition description is poor, errors are : inconsistent). :-) I found that on both Linux and Mac OS X, the queue.h's : didn't have everything I wanted. : : Nice! Thank you Robert. Can I copy parts of this and add them to the : autoconf glue I'm adding now? : : To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, : which I used when I tried writing a check for __FBSDID(): : : AC_PREPROC_IFELSE( : [AC_LANG_PROGRAM([[#include sys/cdefs.h : #ifndef __FBSDID : #error No __FBSDID definition. : #endif]])], : [AC_DEFINE([HAVE_FBSDID_MACRO], [1], :[Define to 1 if you have the __FBSDID macro.])]) : : I can probably improve a bit the queue.h check using what you wrote : above and AC_PREPROC_IFELSE(). The alternative to uglifying the make sources with #ifdefs would be to just always use the compat includes when building... No autoconf needed, and minimal changes to the base make, if any. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] Harti Brandt [EMAIL PROTECTED] writes: : On Tue, 4 Mar 2008, M. Warner Losh wrote: : : MWLIn message: [EMAIL PROTECTED] : MWLGiorgos Keramidas [EMAIL PROTECTED] writes: : MWL: On 2008-03-04 15:38, Robert Watson [EMAIL PROTECTED] wrote: : MWL: On Tue, 4 Mar 2008, M. Warner Losh wrote: : MWL: : MWL: : In most ports of FreeBSD parts to Linux that I've seen, the preferred solution : MWL: : has to been to bring the entire FreeBSD queue.h with you rather than relying : MWL: : on the native Linux queue.h. This is what we do for OpenBSM, for example; : MWL: : this also helps out when you get to Mac OS X, Solaris, etc, where all the : MWL: : queue.h's continue to vary in subtle ways. This depends a fair amount on a : MWL: : lack of header pollution in the OS's own include files, of course... : MWL: : MWL: I was rather hoping for something that could be used without any of that : MWL: nonsense... : MWL: : MWL: Sadly, nonsense seems to be the name of the game in software portability. : MWL: Here's the broken autoconf garbage I use to pick out adequate queue.h's : MWL: from inadequate ones: : MWL: : MWL: # sys/queue.h exists on most systems, but its capabilities vary a great deal. : MWL: # test for LIST_FIRST and TAILQ_FOREACH_SAFE, which appears to not exist in : MWL: # all of them, and are necessary for OpenBSM. : MWL: AC_TRY_LINK([ : MWL: #include sys/queue.h : MWL: ], [ : MWL: : MWL: #ifndef LIST_FIRST : MWL: #error LIST_FIRST missing : MWL: #endif : MWL: #ifndef TAILQ_FOREACH_SAFE : MWL: #error TAILQ_FOREACH_SAFE : MWL: #endif : MWL: ], [ : MWL: AC_DEFINE(HAVE_FULL_QUEUE_H,, Define if queue.h includes LIST_FIRST) : MWL: ]) : MWL: : MWL: Note that there are at least a couple of mostly stylistic bugs there (could : MWL: use compile rather than link, definition description is poor, errors are : MWL: inconsistent). :-) I found that on both Linux and Mac OS X, the queue.h's : MWL: didn't have everything I wanted. : MWL: : MWL: Nice! Thank you Robert. Can I copy parts of this and add them to the : MWL: autoconf glue I'm adding now? : MWL: : MWL: To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, : MWL: which I used when I tried writing a check for __FBSDID(): : MWL: : MWL: AC_PREPROC_IFELSE( : MWL: [AC_LANG_PROGRAM([[#include sys/cdefs.h : MWL: #ifndef __FBSDID : MWL: #error No __FBSDID definition. : MWL: #endif]])], : MWL: [AC_DEFINE([HAVE_FBSDID_MACRO], [1], : MWL:[Define to 1 if you have the __FBSDID macro.])]) : MWL: : MWL: I can probably improve a bit the queue.h check using what you wrote : MWL: above and AC_PREPROC_IFELSE(). : MWL : MWLThe alternative to uglifying the make sources with #ifdefs would be to : MWLjust always use the compat includes when building... No autoconf : MWLneeded, and minimal changes to the base make, if any. : : Yes, please, please don't put #ifdefs into make. It took months to get rid : of the cruft that was there and to make it at least somewhat readable. A : single compat.h or whatever header file plus, maybe a compat.c file should : be sufficient. They can, of course, contain ifdefs. Just include compat.h : in all make's c-files. So far I've seen a need only for one ifdef for the pc98 hack. The rest can be papered over with compat files. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : On 2008-03-04 08:52, M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Giorgos Keramidas [EMAIL PROTECTED] writes: : : Nice! Thank you Robert. Can I copy parts of this and add them to the : : autoconf glue I'm adding now? : : : : To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, : : which I used when I tried writing a check for __FBSDID(): : : : : AC_PREPROC_IFELSE( : : [AC_LANG_PROGRAM([[#include sys/cdefs.h : : #ifndef __FBSDID : : #error No __FBSDID definition. : : #endif]])], : : [AC_DEFINE([HAVE_FBSDID_MACRO], [1], : :[Define to 1 if you have the __FBSDID macro.])]) : : : : I can probably improve a bit the queue.h check using what you wrote : : above and AC_PREPROC_IFELSE(). : : The alternative to uglifying the make sources with #ifdefs would be to : just always use the compat includes when building... No autoconf : needed, and minimal changes to the base make, if any. : : True. I'll try to keep #ifdef changes down to the absolutely _minimum_ : amount of changes. It will make repeated merged from usr.bin/make much : easier, for example :) Lemme put together a package for all this and see how few ifdefs I can do it with... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: : #include arch.h : +#include config.h : : Are you able to use CFLAGS+= -include config.h instead? : If so, that would mean less .[ch] changes. It turns out that there's an even easier way to do this. If I just package a custom err.h with the stock cdefs.h and queue.h, I can avoid almost all the other changes. I'm working on testing that scenario right now. But that is a good point... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
In message: [EMAIL PROTECTED]
Christoph Hellwig [EMAIL PROTECTED] writes:
: On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote:
: +#ifndef TAILQ_HEAD_INITIALIZER
: +#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
: +#endif
: +
: +#ifndef TAILQ_FOREACH
: +#defineTAILQ_FOREACH(var, head, field)
\
: + for ((var) = TAILQ_FIRST((head)); \
: + (var); \
: + (var) = TAILQ_NEXT((var), field))
: +#endif
:
: ...
:
: I think you might be better off with a shadow include/ directory
: that provides a current sys/queue.h on Linux which is what quite a few
: other packages do. I've tried updating the on in glibc a few years ago
: but the maintainer refused to take it.
OK. I think I'll go this route because doing so I have even fewer
changes necessary.
btw, did he give a reason?
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Comments on pmake diffs for building on Linux
Greetings,
here's a set of diffs that will allow FreeBSD's usr.bin/make to build
on Linux. I'm sure they are gross, and I don't plan to commit them
(at least not all of them), but I thought I'd post them here to see
what people think.
I think that the extra config.h includes, the errc - errx patches and
the Makefile.dist patches may be good for the tree. The rest may not
meet FreeBSD's source tree policies.
Comments?
Warner
diff -ur pmake.orig/config.h pmake/config.h
--- pmake.orig/config.h 2005-02-01 03:50:35.0 -0700
+++ pmake/config.h 2008-03-03 22:24:16.745493000 -0700
@@ -108,4 +108,27 @@
# endif
#endif
+#ifndef TAILQ_HEAD_INITIALIZER
+#define TAILQ_HEAD_INITIALIZER(head) { NULL, (head).tqh_first }
+#endif
+
+#ifndef TAILQ_FOREACH
+#defineTAILQ_FOREACH(var, head, field)
\
+ for ((var) = TAILQ_FIRST((head)); \
+ (var); \
+ (var) = TAILQ_NEXT((var), field))
+#endif
+
+#ifndef TAILQ_FIRST
+#defineTAILQ_FIRST(head) ((head)-tqh_first)
+#endif
+
+#ifndef TAILQ_NEXT
+#defineTAILQ_NEXT(elm, field) ((elm)-field.tqe_next)
+#endif
+
+#ifndef TAILQ_EMPTY
+#defineTAILQ_EMPTY(head) ((head)-tqh_first == NULL)
+#endif
+
#endif /* config_h_efe0765e */
diff -ur pmake.orig/dir.c pmake/dir.c
--- pmake.orig/dir.c2005-03-23 05:56:15.0 -0700
+++ pmake/dir.c 2008-03-03 22:22:36.072235000 -0700
@@ -93,6 +93,7 @@
#include unistd.h
#include arch.h
+#include config.h
#include dir.h
#include globals.h
#include GNode.h
Only in pmake: log
diff -ur pmake.orig/main.c pmake/main.c
--- pmake.orig/main.c 2007-12-18 15:58:14.0 -0700
+++ pmake/main.c2008-03-03 22:25:47.543349000 -0700
@@ -63,7 +63,9 @@
#include sys/param.h
#include sys/stat.h
+#ifdef __FreeBSD__
#include sys/sysctl.h
+#endif
#include sys/time.h
#include sys/queue.h
#include sys/resource.h
@@ -366,7 +368,9 @@
rearg:
optind = 1; /* since we're called more than once */
+#ifndef linux
optreset = 1;
+#endif
#define OPTFLAGS ABC:D:E:I:PSV:Xd:ef:ij:km:nqrstvx:
for (;;) {
if ((optind argc) strcmp(argv[optind], --) == 0) {
@@ -660,11 +664,9 @@
int level = (value == NULL) ? 0 : atoi(value);
if (level 0) {
- errc(2, EAGAIN, Invalid value for recursion level (%d).,
- level);
+ errx(2, Invalid value for recursion level (%d)., level);
} else if (level MKLVL_MAXVAL) {
- errc(2, EAGAIN, Max recursion level (%d) exceeded.,
- MKLVL_MAXVAL);
+ errx(2, Max recursion level (%d) exceeded., MKLVL_MAXVAL);
} else {
char new_value[32];
sprintf(new_value, %d, level + 1);
@@ -931,6 +933,7 @@
}
#endif
+#ifdef __FreeBSD__
/*
* FreeBSD/pc98 kernel used to set the utsname.machine to
* i386, and MACHINE was defined as i386, so it could
@@ -951,6 +954,7 @@
machine = pc98;
}
}
+#endif
/*
* Get the name of this type of MACHINE from utsname
diff -ur pmake.orig/Makefile.dist pmake/Makefile.dist
--- pmake.orig/Makefile.dist2007-12-18 15:58:14.0 -0700
+++ pmake/Makefile.dist 2008-03-03 22:27:31.71124 -0700
@@ -2,7 +2,7 @@
# a simple makefile to help builds on !FreeBSD systems
pmake:
@echo 'make started.'
- cc -D__FBSDID=static const char *id= -DDEFSHELLNAME=\sh\ -I. -c *.c
+ cc -D__dead2= -D__unused= -Darc4random=random -D__FBSDID=static
const char *id= -DDEFSHELLNAME=\sh\ -I. -c *.c
cc *.o -o pmake
@echo 'make completed.'
diff -ur pmake.orig/shell.c pmake/shell.c
--- pmake.orig/shell.c 2005-05-24 09:30:03.0 -0600
+++ pmake/shell.c 2008-03-03 22:20:08.597377000 -0700
@@ -45,6 +45,7 @@
#include stdlib.h
#include string.h
+#include config.h
#include parse.h
#include pathnames.h
#include shell.h
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Mon, Feb 25, 2008 at 12:07:44AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Mike Meyer [EMAIL PROTECTED] writes: : You fail to understand the complex interplay of politics here. These : people do not want to see beyond it. They want to shut you down : because you aren't using their beloved Linux. They use stupid excuses : to not do things. This is about removing barriers to entry. This : isn't about being popular. : .. : : Um, if FreeBSD has to become GNU in order to win GNU users, what's the : : point? Skip the pain, switch to GNU, and get the popularity you want : : and the platform you deserve with no delay. : : Hello? BSDL calling. You left your GPL here and we don't want it. : : For some of these uses of FreeBSD - I really have to wonder if : GNU/kFreeBSD (Debian GNU/kFreeBSD is a port that consists of GNU userland : using the GNU C library on top of FreeBSD's kernel) isn't a better : choice. http://www.debian.org/ports/kfreebsd-gnu/ : : One can keep their kernel changes private IP without worry. I doubt most : companies would claim they have IP that needs protecting in their GNU : userland changes. True, but using the GPL goes beyond just giving out your changes. If you mess up in shipping your product, even once, even by accident, the GPL has a provision that terminates your license, so you are unable to ship that work any more until you go back to the license hold and get it restored. This aspect of the GPL is used by GPL-trolls to extract payments from companies. It is also little enforced by other IP holders if you make it right. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED]
Stanislav Sedov [EMAIL PROTECTED] writes:
: Should be, probably, spelled as GNU, it's an abbrev.
Actually, you are right, but for the wrong reason. GNU is an acronym,
so should be all caps.
: -/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or */
: +/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or,
c_true, c_false */
:
:
: As the result of modification the line now exceeds 80 characters, which is,
obviously, bad.
I have a couple of other places to clean up.
: Index: option.c
: ===
: RCS file: /cache/ncvs/src/usr.bin/find/option.c,v
: retrieving revision 1.25
: diff -u -r1.25 option.c
: --- option.c5 Apr 2006 23:06:11 - 1.25
: +++ option.c23 Feb 2008 06:57:54 -
: @@ -58,6 +58,7 @@
: int typecompare(const void *, const void *);
:
: /* NB: the following table must be sorted lexically. */
: +/* Options listed with C++ comments are in gnu find, but not our find */
:
: Please, don't commit C++ comments, that violates style(9). Also, gnu should be
: spelled as GNU.
Understood. Not that I'm going to change it, but understood.
: static OPTION const options[] = {
: { !, c_simple, f_not, 0 },
: { (, c_simple, f_openparen,0 },
: @@ -74,26 +75,38 @@
: { -cmin, c_Xmin, f_Xmin, F_TIME_C },
: { -cnewer,c_newer,f_newer,F_TIME_C },
: { -ctime, c_Xtime,f_Xtime,F_TIME_C },
: + { -d, c_depth,f_depth,0 },
: +// -daystart
: { -delete,c_delete, f_delete, 0 },
: { -depth, c_depth,f_depth,0 },
:
: Why to add just a shortcut for already existent -depth option?
: It makes the utility much complex, but don't add value at all.
Because it makes it more compatible with existing de-facto standards.
It costs us very little to do so.
: { -empty, c_empty,f_empty,0 },
: { -exec, c_exec, f_exec, 0 },
: { -execdir, c_exec, f_exec, F_EXECDIR },
: - { -false, c_simple, f_not, 0 },
: + { -false, c_simple, f_false,0 },
:
: This brakes FreeBSD compatiblity in the favor of GNU. What will
: old FreeBSD user think when his scripts will stop working
: after next cvsup? I suppose our target not to make FreeBSD
: to look like Linux. If you want to add GNU-like false option,
: please, add it under the different name.
I considered it, but rejected it. The current -false option doesn't
make any sense at all, likely isn't used, is just a short-cut for '!'
and had a very dubious justification when it was committed.
: No space between -iwholename and c_name.
:
: Also, just a shortcut to -ipath. Also, -iname is much shorter.
Again, for compatibility with existing scripts. I didn't pick the
names here.
: { -links, c_links,f_links,0 },
: + { -lname, c_name, f_name, F_LINK },
: { -ls,c_ls, f_ls, 0 },
: { -maxdepth, c_mXXdepth, f_always_true, F_MAXDEPTH },
: { -mindepth, c_mXXdepth, f_always_true, 0 },
: { -mmin, c_Xmin, f_Xmin, 0 },
: { -mnewer,c_newer,f_newer,0 },
: + { -mount, c_xdev, f_always_true, 0 },
:
: SHortuct to -xdev. Again, much longer one.
Agreed, but for compatibility with existing scripts...
: Warner, I fully understand your intention to make FreeBSD more
: compatible with GNU, but FreeBSD Project historically had much more
: important target - to make a clean designed and not bloated
: system. I'll be happy to see new useful options added to find, but
: in case they isn't just shortcuts to existing ones and don't break
: existing functionality.
There's at least one that adds real, new functionality (-lname and
-ilname). The minor breakage to FreeBSD users for -false likely will
affect fewer people than the removal of the 'ie' driver.
: If'll take a direction to become a Linux one day - we'll certainly
: loose. There'a lot of examples of this in history - I don't want to
: make the same mistake. It's quite common for BSD and GNU world to
: make different desicions on design of their systems. That's pretty
: normal. BSD people tend to prefer a clean and simple design, where
: duplication is a bad thing, where GNU people prefer to implement
: every possible functionality in their programs. Linux camp - is
: 'just works' camp, where BSD - 'works perfectly' camp.
It can be a tough judgment call here. While I generally favor
cleanliness, there's also a lot of gain to be had with being
compatible.
: I understand, that you want to attract more people from the
: GNU/Linux camp to FreeBSD. But think - people go from Linux to
: FreeBSD for a reason, a
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : On Sun, 24 Feb 2008 21:28:44 -0800 Julian Elischer [EMAIL PROTECTED] wrote: : It's been in my tradition for Unix developement since 1986 when I : first joined comp.unix : : It has happened. But from my perspective, what happened going from v6 : to v7 tends to be the rule, and your tradition is the exception. Then clearly you haven't been paying attention. While many of the attempts to make different versions of Unix compatible have failed, the attempts have been there from the start. In addition, all of the tools in the tree that aren't based on gnu tools have had many gnu extensions added continuously over the course of the years in FreeBSD. : If you saw what Warner and others have to do to in battling the Linux : hordes, you'd also be looking to remove all the trivial complaints : that are made as excuses to not use BSD. : : No, I wouldn't. You're assuming that popularity is inherently a good : thing, which is a common misconception I don't share. Popularity has nothing to do with it. : More accurately, : I don't believe that popularity is in and of itself a good thing, to : be catered to at all costs. Makes me wonder if there's a connection : between GNU distros treating their users like idiots and those same : users not being able to see beyond the trivialities. You fail to understand the complex interplay of politics here. These people do not want to see beyond it. They want to shut you down because you aren't using their beloved Linux. They use stupid excuses to not do things. This is about removing barriers to entry. This isn't about being popular. : I think that we have to make a conscious decision as a project to : acknowledge the position we find ourselves in WRT 3rd party software : and make moves to lower the barriers to entry as much as we can. : : Um, if FreeBSD has to become GNU in order to win GNU users, what's the : point? Skip the pain, switch to GNU, and get the popularity you want : and the platform you deserve with no delay. Hello? BSDL calling. You left your GPL here and we don't want it. It is funny, but the same sorts of arguments were made against POSIX constructs only a few years ago. They were evil. Something was wrong with them. But they have proven to be OK in the fullness of time, and POSIX now is the exception rather than the rule. It was proposed back in 1990 or so, and it took until the early part of this century to be adopted. Many of the GNU tools are about 5 years behind that curve. : Of course, since GNU is well on the way to becoming Windows in order : to get people to switch to GNU from Windows, maybe we should just skip : a step and start catering to Windows users? After all, there are an : order of magnitude more of them... Ture, but irrelevant. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : On Sat, 23 Feb 2008 00:03:08 -0700 (MST) M. Warner Losh [EMAIL PROTECTED] wrote: : : Sorry to be lame and follow up to my original email, but Ruslan was : way too quick to give me feedback :-) : : I also did a few more of the really easy ones, and added a list of : ones that we haven't implemented yet. : : Comments? : : How about a question: why are you turning the FreeBSD find into the : GNU find? The changes in the first patch looked like they added real : functionality that wasn't available in other tools. These seem to be : gratuitous changes to make things compatible with GNU. The changes aren't gratuitous. They are well thought out to ensure maximum compatibility. : If I want a GNU-compatible find on FreeBSD, I can install the : misc/findutils port. If I really wanted the GNU toolset, I could run : them on a Linux kernel. However, I'm more comfortable with the Unix : toolset (which GNU, as it's own name points out, *isn't*), so the : direction taken by these patches make me more than a bit : uncomfortable. I looked for a bit last night and couldn't find the gnu find port. It was faster and easier for me to implement the trivial bit of functionality in our find than to try to compile gnu's findutils from scratch. I know, I'm lame because I could find it in the list, so that's a weak excuse. : Hence the question: why are you turning the FreeBSD find into the GNU : find? Because, frankly, I'm getting tired of installing the gnu versions of the tools for trivial reasons. I don't like doing that. Openwrt requires certain features of GNU find. There's no reason why these features shouldn't be present in the base system find. None. It is absolutely silly install a whole other program when our find would need such trivial tweaks to make it work. It is yet another barrier to entry for people converting from Linux to FreeBSD. There's lots of useful scripts that have been written for the embedded world that, sadly, assume more functionality in our tools than are present. They don't always do nice autoconf things to find the right tool to use. The trivial differences between gnu find and our find serve no real purpose. I can dig up numbers for the size difference in the code, but my experience tells me it is less than 1k. This is a lot more efficient than installing gnufind, which must be 1k in size. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: : In short, I'm continuig the long tradition that we've done as FreeBSD : and that BSD and other Unix vendors did before us: compatibility with : other implementations. : : I suspect your definition of long tradition is a lot shorter than : mine. That's they only way I can make that statement make sense - at : least the part about BSD and other Unix vendors. Long tradition here spans about 30 years. SunOS 3.5 had many switches that did nothing, but were there for compatibility with System III systems, as one example. If you look at the evolution of /bin/sh in FreeBSD you'll notice that over the years it has accumulated much that is POSIX. If you look at the evolution of FreeBSD itself, you'll notice a change from a 'POSIX is evil, except where proven otherwise' mindset to a 'POSIX is a good thing, except where proven otherwise.' Lots of people hated POSIX back in the day, but today you'll not find too many people still in that camp. POSIX used to be less well defined than it is today. The GNU extensions have even been standardized as POSIX extensions over the years. It is my belief, based on experience in bringing over tools from other systems (read Linux) that there's a need to support these extensions, much like there was a need to support POSIX semantics 10 years ago. While not well codified, they are none-the-less in widespread use. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Jonathan McKeown [EMAIL PROTECTED] writes: : What functionality does : : find path -lname name : : add that isn't already available from : : find path -name name -type l : : and what other combinations should be special-cased like this? What it does is make busybox and openwrt scrpits work better. One could argue that one should change the scripts, but that's not likely to happen. What does -iname add that a properly constructed regular expression for the name not have? Convenience. So apart from the fact that it is used in real scripts, it is also more convenient. Why do we use tools with short cuts? Because it saves us time. : Yes, where it makes sense. I'm not at all convinced that this change makes as : much sense as you obviously think it does - especially given that it doesn't : add previously unavailable functionality, and that we have a ports system : which includes a patch stage for dealing with this sort of gratuitous : non-portability in ported applications. The change absolutely makes sense, and so far none of the arguments against it are really worth the time to respond to. I'm using packages not in the ports system. Frankly, the more gratuitous differences with the gnu tools we have, the harder the sell will be for companies wanting to replace their Linux systems with FreeBSD ones. The changes I made were absolutely trivial in the scheme of things. This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : At the same, time, the find(1) man page needs to clearly distinguish : between the parts of find that are POSIX-complaint, the parts that are : GNU extensions and the parts that are [Free]BSD extensions. This is : necessary so that when I'm developing tools, I can avoid non-portable : extensions (unlike whoever developed the scripts Warner is trying to : use). If the FreeBSD project does not make it clear what functionality : is safe to rely on then we run the risk of falling into the Linux trap : where people write bash scripts because they believe it is the standard. All the GNU extensions were flagged as such when I committed the man page updates. However, if I missed one or two, or if there's other extensions to posix that aren't tagged as such, I'll be happy to do the leg work to tag them better in the man page. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : On Sat, Feb 23, 2008 at 04:50:02PM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Peter Jeremy [EMAIL PROTECTED] writes: : : At the same, time, the find(1) man page needs to clearly distinguish : : between the parts of find that are POSIX-complaint, the parts that are : : GNU extensions and the parts that are [Free]BSD extensions. : : All the GNU extensions were flagged as such when I committed the man : page updates. : : I wrote my email before I saw that you had actually committed the : changes. My comment was a general comment and was not intended as : a slight on your man page changes. My apologies for any offence I : may have inadvertently caused. No offense taken. I'm serious: if there's ways we can make find(1) better, I'm all ears. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
find -lname and -ilname implemented
Please find enclosed a patch that implements -lname and -ilname in
FreeBSD's find. There's some shell scripts that insist on these gnu
findtools features.
Comments?
Warner
Index: find.1
===
RCS file: /cache/ncvs/src/usr.bin/find/find.1,v
retrieving revision 1.82
diff -u -r1.82 find.1
--- find.1 28 Feb 2007 10:19:25 - 1.82
+++ find.1 23 Feb 2008 05:57:30 -
@@ -436,6 +436,10 @@
is numeric and there is no such group name, then
.Ar gname
is treated as a group ID.
+.It Ic -ilname Ar pattern
+Like
+.Ic -lname ,
+but the match is case insensitive.
.It Ic -iname Ar pattern
Like
.Ic -name ,
@@ -455,6 +459,10 @@
True if the file has
.Ar n
links.
+.It Ic -lname Ar pattern
+Like
+.Ic -name ,
+but the must also be a symbolic link.
.It Ic -ls
This primary always evaluates to true.
The following information for the current file is written to standard output:
Index: find.h
===
RCS file: /cache/ncvs/src/usr.bin/find/find.h,v
retrieving revision 1.19
diff -u -r1.19 find.h
--- find.h 14 May 2006 20:23:01 - 1.19
+++ find.h 22 Feb 2008 19:38:21 -
@@ -74,6 +74,7 @@
#define F_EXECPLUS 0x0002 /* -exec ... {} + */
#defineF_TIME_B0x0004 /* one of -Btime, -Bnewer,
-newerB* */
#defineF_TIME2_B 0x0008 /* one of -newer?B */
+#define F_LINK 0x0010 /* lname or liname */
/* node definition */
typedef struct _plandata {
Index: function.c
===
RCS file: /cache/ncvs/src/usr.bin/find/function.c,v
retrieving revision 1.58
diff -u -r1.58 function.c
--- function.c 27 May 2006 18:27:41 - 1.58
+++ function.c 22 Feb 2008 19:50:13 -
@@ -1063,6 +1063,8 @@
int
f_name(PLAN *plan, FTSENT *entry)
{
+ if ((plan-flags F_LINK) !S_ISLNK(entry-fts_statp-st_mode))
+ return 0;
return !fnmatch(plan-c_data, entry-fts_name,
plan-flags F_IGNCASE ? FNM_CASEFOLD : 0);
}
@@ -1076,6 +1078,8 @@
pattern = nextarg(option, argvp);
new = palloc(option);
new-c_data = pattern;
+ if (new-flags F_LINK)
+ ftsoptions = ~FTS_NOSTAT;
return new;
}
Index: option.c
===
RCS file: /cache/ncvs/src/usr.bin/find/option.c,v
retrieving revision 1.25
diff -u -r1.25 option.c
--- option.c5 Apr 2006 23:06:11 - 1.25
+++ option.c22 Feb 2008 19:37:33 -
@@ -88,7 +88,9 @@
{ -inum, c_inum, f_inum, 0 },
{ -ipath, c_name, f_path, F_IGNCASE },
{ -iregex,c_regex,f_regex,F_IGNCASE },
+ { -liname,c_name, f_name, F_LINK | F_IGNCASE },
{ -links, c_links,f_links,0 },
+ { -lname, c_name, f_name, F_LINK },
{ -ls,c_ls, f_ls, 0 },
{ -maxdepth, c_mXXdepth, f_always_true, F_MAXDEPTH },
{ -mindepth, c_mXXdepth, f_always_true, 0 },
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
Sorry to be lame and follow up to my original email, but Ruslan was
way too quick to give me feedback :-)
I also did a few more of the really easy ones, and added a list of
ones that we haven't implemented yet.
Comments?
Warner
Index: extern.h
===
RCS file: /cache/ncvs/src/usr.bin/find/extern.h,v
retrieving revision 1.23
diff -u -r1.23 extern.h
--- extern.h14 May 2006 20:23:00 - 1.23
+++ extern.h23 Feb 2008 06:23:02 -
@@ -90,6 +90,7 @@
exec_f f_empty;
exec_f f_exec;
exec_f f_expr;
+exec_f f_false;
exec_f f_flags;
exec_f f_fstype;
exec_f f_group;
Index: find.1
===
RCS file: /cache/ncvs/src/usr.bin/find/find.1,v
retrieving revision 1.82
diff -u -r1.82 find.1
--- find.1 28 Feb 2007 10:19:25 - 1.82
+++ find.1 23 Feb 2008 06:53:39 -
@@ -293,6 +293,12 @@
Please refer to the
.Ic -atime
primary description for information on supported time units.
+.It Ic -d
+Same as
+.Ic depth .
+Gnu find implements this as a primary in mistaken emulation of
+.Fx
+.Xr find 1 .
.It Ic -delete
Delete found files and/or directories.
Always returns true.
@@ -365,6 +371,15 @@
the string
.Dq Li {}
is not qualified.
+.It Ic -execdir Ar utility Oo Ar argument ... Oc Li {} +
+Same as
+.Ic -execdir ,
+except that
+.Dq Li {}
+is replaced with as many pathnames as possible for each invocation of
+.Ar utility .
+This behaviour is similar to that of
+.Xr xargs 1 .
.It Ic -flags Oo Cm - Ns | Ns Cm + Oc Ns Ar flags , Ns Ar notflags
The flags are specified using symbolic names (see
.Xr chflags 1 ) .
@@ -436,6 +451,10 @@
is numeric and there is no such group name, then
.Ar gname
is treated as a group ID.
+.It Ic -ilname Ar pattern
+Like
+.Ic -lname ,
+but the match is case insensitive.
.It Ic -iname Ar pattern
Like
.Ic -name ,
@@ -451,10 +470,18 @@
Like
.Ic -regex ,
but the match is case insensitive.
+.It Ic -iwholename Ar pattern
+The same thing as
+.Ic -ipath ,
+for Gnu find compatibility.
.It Ic -links Ar n
True if the file has
.Ar n
links.
+.It Ic -lname Ar pattern
+Like
+.Ic -name ,
+but the matched file must also be a symbolic link.
.It Ic -ls
This primary always evaluates to true.
The following information for the current file is written to standard output:
@@ -497,6 +524,10 @@
.It Ic -mnewer Ar file
Same as
.Ic -newer .
+.It Ic -mount
+The same thing as
+.Ic -xdev ,
+for Gnu find compatibility.
.It Ic -mtime Ar n Ns Op Cm smhdw
If no units are specified, this primary evaluates to
true if the difference between the file last modification time and the time
@@ -747,6 +778,10 @@
is numeric and there is no such user name, then
.Ar uname
is treated as a user ID.
+.It Ic -wholename Ar pattern
+The same thing as
+.Ic -path ,
+for Gnu find compatibility.
.El
.Pp
All primaries which take a numeric argument allow the number to be
@@ -770,13 +805,17 @@
true.
.Pp
.It Cm \! Ar expression
-.It Cm -false Ar expression
.It Cm -not Ar expression
This is the unary
.Tn NOT
operator.
It evaluates to true if the expression is false.
.Pp
+.It Cm -false
+Always false.
+.It Cm -true
+Always true.
+.Pp
.It Ar expression Cm -and Ar expression
.It Ar expression expression
The
Index: find.h
===
RCS file: /cache/ncvs/src/usr.bin/find/find.h,v
retrieving revision 1.19
diff -u -r1.19 find.h
--- find.h 14 May 2006 20:23:01 - 1.19
+++ find.h 23 Feb 2008 06:54:11 -
@@ -74,6 +74,7 @@
#define F_EXECPLUS 0x0002 /* -exec ... {} + */
#defineF_TIME_B0x0004 /* one of -Btime, -Bnewer,
-newerB* */
#defineF_TIME2_B 0x0008 /* one of -newer?B */
+#define F_LINK 0x0010 /* lname or ilname */
/* node definition */
typedef struct _plandata {
Index: function.c
===
RCS file: /cache/ncvs/src/usr.bin/find/function.c,v
retrieving revision 1.58
diff -u -r1.58 function.c
--- function.c 27 May 2006 18:27:41 - 1.58
+++ function.c 23 Feb 2008 06:29:16 -
@@ -474,7 +474,7 @@
/*
* always_true --
*
- * Always true, used for -maxdepth, -mindepth, -xdev and -follow
+ * Always true, used for -maxdepth, -mindepth, -xdev, -follow, and -true
*/
int
f_always_true(PLAN *plan __unused, FTSENT *entry __unused)
@@ -1063,6 +1063,8 @@
int
f_name(PLAN *plan, FTSENT *entry)
{
+ if ((plan-flags F_LINK) !S_ISLNK(entry-fts_statp-st_mode))
+ return 0;
return !fnmatch(plan-c_data, entry-fts_name,
plan-flags F_IGNCASE ? FNM_CASEFOLD : 0);
}
@@ -1076,6 +1078,8 @@
pattern = nextarg(option, argvp);
new = palloc(option);
new-c_data = pattern;
+ if (new-flags F_LINK)
+ ftsoptions = ~FTS_NOSTAT;
return new;
}
@@ -1353,7 +1357,7 @@
Re: encrypted executables
In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : On 2008-02-18 19:54, Jerry Toung [EMAIL PROTECTED] wrote: : On Feb 18, 2008 5:39 PM, Dimitry Andric [EMAIL PROTECTED] wrote: : On 2008-02-19 02:18, Jerry Toung wrote: : anybody knows of a tool to encrypt executables under FreeBSD? may be : from the ports? I am not talking about simple file encryption. : : Can you elaborate on what you *are* talking about then? Some : security-by-obscurity scheme, perhaps? :) : : I need to encrypt elf binaries. I'd like to make it harder for the bad : guy to reverse engineer my app. : : You know about truss/ktrace/strace already, right? : : It may be moot to encrypt the ELF binary, if the `bad guy' can access : the running image of the process *after* it has been decrypted to : execute. kill -ABRT will generate a core file. Often times, the core file can be quite useful in recovering the original executable. emacs has used this technique for years to 'preload' stuff, take a core dump, then re-run the core file after some post-processing. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NOR flash drivers
In message: [EMAIL PROTECTED] Andrew Duane [EMAIL PROTECTED] writes: : I may have asked this once before, but are any NOR flash drivers : available in FreeBSD? I have support that I put into the bootstrap I'm : building, interfaced to libstand, but it is read-only, and far from : useful for a real UFS. I believe that there's a dev/cfi floating around out there. I believe this supports NOR, but I get it and NAND confused. It is in the e500 branch of perforce. I think Marcel committed it. I don't know how close it is to working. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: select
In message: [EMAIL PROTECTED] Metin KAYA [EMAIL PROTECTED] writes: :Yes Rick, I'm asking this indefinitely issue. Is there anything :that handle this NULL situation a signal, or etc.? How does Linux or :FreeBSD behave? : : On Thu, Jan 03, 2008 at 08:52:48PM +0200, Metin KAYA wrote: : :How select(2) will behave if I give the utimeout parameter as :NULL? : : According to the man page: : : If timeout is not a null pointer, it specifies the maximum interval to : wait for the selection to complete. System activity can lengthen the : interval by an indeterminate amount. : : If timeout is a null pointer, the select blocks indefinitely. : : To effect a poll, the timeout argument should not be a null pointer, but : it should point to a zero-valued timeval structure. : Indefinitely means it won't return until there's an error or data Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Architectures with strict alignment?
In message: [EMAIL PROTECTED] Ivan Voras [EMAIL PROTECTED] writes: : Which of the architectures FreeBSD supports (if any) have strict memory : alignment requirements? (in the sense that accessing a 32-bit integer : not aligned on a 32-bit address results in a hardware trap/exception). Sparc64, powerpc, arm, and (thanks to Juniper and others) mips. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some diffs
In message: [EMAIL PROTECTED]
John Baldwin [EMAIL PROTECTED] writes:
: Was the bsd.prog.mk change accidentally included?
:
: //depot/projects/arm/src/share/mk/bsd.prog.mk#4 -
/Users/imp/p4/arm/src/share/mk/bsd.prog.mk
: @@ -110,17 +110,18 @@
:
: .if defined(PROG)
: _EXTRADEPEND:
: -.if defined(LDFLAGS) !empty(LDFLAGS:M-nostdlib)
: +.if !defined(FOREIGN_BUILD)
: .if defined(DPADD) !empty(DPADD)
: echo ${PROG}: ${DPADD} ${DEPENDFILE}
: .endif
: -.else
: +.if defined(LDFLAGS) !empty(LDFLAGS:M-nostdlib)
: echo ${PROG}: ${LIBC} ${DPADD} ${DEPENDFILE}
: .if defined(PROG_CXX)
: echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
: .endif
: .endif
: .endif
: +.endif
:
: .if !target(install)
FreeBSD's build systems assumes bad things. This is one nobody has
noticed. Even when compiling purely dynamic, it tries to create a
.depend file with libc.a... Or any .a for that matter. OS X doesn't
have any .a's to speak of, so this was failing. It is part of another
change that tries to hack together enough of an environment to make
things build under OS X, but I hit the wall in binutils and need to
rethink my approach.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some diffs
In message: [EMAIL PROTECTED]
Diomidis Spinellis [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
: And the last, rather long, patch converts the .y in config to a form
: that more versions of yacc would grok.
:
: Comments?
: [...]
: - INCLUDE ID SEMICOLON
: - = {
: + INCLUDE ID SEMICOLON {
: [...]
:
: The = { way for specifying yacc actions is item 5 in yacc's Appendix D
: titled Old Features Supported but not Encouraged in the Seventh
: Edition Unix Programmer's Manual (January, 1979). I believe it's now
: time to make the switch. Thanks!
We can't switch until the feature has been deprecated for 30 years or
more, right?
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Some diffs
Consider the following diffs. The first one does a tiny cleanup of
strfile's include style (no real reason other than it bugged me when I
added stdint.h).
The second one cleans up a minor problem where ${CFLAGS} isn't used
where it should be.
The next three cleanup the compilation by not assuming sys/types.h is
included or by also including stdint.h
And the last, rather long, patch converts the .y in config to a form
that more versions of yacc would grok.
Comments?
Warner
//depot/projects/arm/src/games/fortune/strfile/strfile.c#1 -
/Users/imp/p4/arm/src/games/fortune/strfile/strfile.c
@@ -48,16 +48,17 @@
#include sys/cdefs.h
__FBSDID($FreeBSD: src/games/fortune/strfile/strfile.c,v 1.28 2005/02/17
18:06:37 ru Exp $);
-# include sys/param.h
-# include sys/endian.h
-# include stdio.h
-# include stdlib.h
-# include ctype.h
-# include string.h
-# include time.h
-# include locale.h
-# include unistd.h
-# include strfile.h
+#include sys/param.h
+#include sys/endian.h
+#include stdint.h
+#include stdio.h
+#include stdlib.h
+#include ctype.h
+#include string.h
+#include time.h
+#include locale.h
+#include unistd.h
+#include strfile.h
/*
* This program takes a file composed of strings separated by
//depot/projects/arm/src/lib/libmagic/Makefile#2 -
/Users/imp/p4/arm/src/lib/libmagic/Makefile
@@ -40,8 +40,7 @@
CLEANFILES+= mkmagic
build-tools: mkmagic
mkmagic: apprentice.c funcs.c magic.c print.c
- ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
- -I${.CURDIR} -I${CONTRDIR} -o ${.TARGET} ${.ALLSRC}
+ ${CC} -DHAVE_CONFIG_H ${CFLAGS} -o ${.TARGET} ${.ALLSRC}
FILEVER!= awk '$$1 == \#define $$2 == VERSION { print $$3; exit }' \
${.CURDIR}/config.h
//depot/projects/arm/src/share/mk/bsd.prog.mk#4 -
/Users/imp/p4/arm/src/share/mk/bsd.prog.mk
@@ -110,17 +110,18 @@
.if defined(PROG)
_EXTRADEPEND:
-.if defined(LDFLAGS) !empty(LDFLAGS:M-nostdlib)
+.if !defined(FOREIGN_BUILD)
.if defined(DPADD) !empty(DPADD)
echo ${PROG}: ${DPADD} ${DEPENDFILE}
.endif
-.else
+.if defined(LDFLAGS) !empty(LDFLAGS:M-nostdlib)
echo ${PROG}: ${LIBC} ${DPADD} ${DEPENDFILE}
.if defined(PROG_CXX)
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
.endif
+.endif
.if !target(install)
//depot/projects/arm/src/usr.bin/colldef/parse.y#1 -
/Users/imp/p4/arm/src/usr.bin/colldef/parse.y
@@ -30,6 +30,7 @@
__FBSDID($FreeBSD: src/usr.bin/colldef/parse.y,v 1.34 2005/05/21 09:55:05 ru
Exp $);
#include arpa/inet.h
+#include sys/types.h
#include err.h
#include stdarg.h
#include stdio.h
//depot/projects/arm/src/usr.bin/colldef/scan.l#1 -
/Users/imp/p4/arm/src/usr.bin/colldef/scan.l
@@ -36,6 +36,7 @@
#include unistd.h
#include string.h
#include sysexits.h
+#include sys/types.h
#include common.h
#include y.tab.h
//depot/projects/arm/src/usr.bin/mklocale/ldef.h#1 -
/Users/imp/p4/arm/src/usr.bin/mklocale/ldef.h
@@ -38,6 +38,7 @@
*/
#include sys/types.h
+#include stdint.h
/*
* This should look a LOT like a _RuneEntry
//depot/projects/arm/src/usr.sbin/config/config.y#9 -
/Users/imp/p4/arm/src/usr.sbin/config/config.y
@@ -95,6 +95,12 @@
void yyerror(const char *s);
int yywrap(void);
+static void newdev(char *name);
+static void newfile(char *name);
+static void rmdev_schedule(struct device_head *dh, char *name);
+static void newopt(struct opt_head *list, char *name, char *value);
+static void rmopt_schedule(struct opt_head *list, char *name);
+
static char *
devopt(char *dev)
{
@@ -122,14 +128,12 @@
|
Config_spec SEMICOLON
|
- INCLUDE ID SEMICOLON
- = {
+ INCLUDE ID SEMICOLON {
if (incignore == 0)
include($2, 0);
};
|
- FILES ID SEMICOLON
- = { newfile($2); };
+ FILES ID SEMICOLON { newfile($2); };
|
SEMICOLON
|
@@ -137,16 +141,14 @@
;
Config_spec:
- ARCH Save_id
- = {
+ ARCH Save_id {
if (machinename != NULL !eq($2, machinename))
errx(1, %s:%d: only one machine directive is allowed,
yyfile, yyline);
machinename = $2;
machinearch = $2;
} |
- ARCH Save_id Save_id
- = {
+ ARCH Save_id Save_id {
if (machinename != NULL
!(eq($2, machinename) eq($3, machinearch)))
errx(1, %s:%d: only one machine directive is allowed,
@@ -154,15 +156,13 @@
machinename = $2;
machinearch = $3;
} |
- CPU Save_id
- = {
+ CPU Save_id {
struct cputype *cp =
(struct cputype *)calloc(1, sizeof
Re: Floating point in interrupt handler
In message: [EMAIL PROTECTED]
Daan Vreeken [PA4DAN] [EMAIL PROTECTED] writes:
: Hi Warner,
:
: On Wednesday 24 October 2007 23:15:13 you wrote:
: In message: [EMAIL PROTECTED]
:
: Daan Vreeken [PA4DAN] [EMAIL PROTECTED] writes:
: : But what I haven't found is a description of exactly what the kernel is
: : missing to allow floating point operations to be done there.
:
: FPU context is assumed to only change in user processes. You'd have
: to fix the FPU state saving code to cope with it changing everywhere,
: or you'd have to explicitly put the goo to save/restore it around the
: FP you want to do in the kernel.
:
: Issei Suzuki pointed me into the right direction in his reply. (The following
: text is an exact copy of the reply I sent to Issei, but I'll just copy it
: here to show the code)
: If I understand the npx code correctly, there are 2 options when the kernel
: arrives at hardclock() :
: o The current process is using the FPU (fpcurthread != NULL)
: o The current process hasn't used the FPU (yet) since it has been switched to
:(fpcurthread == NULL)
: In the first case, FPU instructions can be used and will not result in a
trap,
: but we should save/restore the FPU state before using them so userland
: doesn't get confused. In the last case FPU instructions result in a trap, so
: we need stop/start_emulating(), but as no one is using the FPU, there is no
: need to save/restore it's state.
:
: With this in mind I've come up with the following code :
:
: At the start of the function :
: // check FPU state on entry
: if (PCPU_GET(fpcurthread) != NULL) {
: // someone is using the FPU
: // save it's state and remember to put it back later
: restore = 1;
: fpusave(fpu_state);
: } else {
: // no one is using the FPU
: // enable use of FPU instructions, no need to save it's state
: restore = 0;
: stop_emulating();
: }
: // init FPU state every time we get here, as we don't know who has
: // been playing with it in between calls
: fninit();
: control = __INITIAL_NPXCW__;
: fldcw(control);
:
: Then we do some floating point arithmetic.
:
: And at the end of the function :
: // restore FPU state before we leave
: if (restore) {
: // restore FPU registers to what they were
: fpurstor(fpu_state);
: } else {
: // no one was using the FPU, so re-enable the FPU trap
: start_emulating();
: }
:
: With this code trap-22 has stopped to trigger within my function. The FPU
: instructions still seem to be executed correctly in my function and when
: adding a couple of printf()'s I can see it fpusave() and fpurstor() when
: interrupting a userland process that uses the FPU.
: Does this look reasonable to everyone?
My concern here would be to make sure that your code doesn't migrate
from one CPU to another. Other than that, I think it is OK.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB vs PAE
In message: [EMAIL PROTECTED] Ivan Voras [EMAIL PROTECTED] writes: : On 24/10/2007, Bob Bishop [EMAIL PROTECTED] wrote: : : Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : 6.2R. Thanks! : : I just saw it is officially ok'ed for PAE in future versions (commit : by John Baldwin). 6.x doesn't have the scatter/gather code merged yet, so still is unsafe. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB vs PAE
In message: [EMAIL PROTECTED] Bob Bishop [EMAIL PROTECTED] writes: : Hi, : : On 23 Oct 2007, at 20:45, Ivan Voras wrote: : : Bob Bishop wrote: : Hi, : : The whole USB kit and caboodle is nodevice'd out in the PAE : config. Can : anyone give a succinct summary of what needs fixing? (EVERYTHING! : is an : acceptable answer) Thanks : : I'm running USB keyboard and mouse under PAE without problems. Don't : know about other USB devices. AFAIK everything that is 64-bit clean : (i.e. works on AMD64 and other architectures) should work ok with PAE, : so try compiling it in and see for yourself. : : : Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : 6.2R. Thanks! In 6.x the big problem is busdma support. USB doesn't use it quite right, which means that buffers that it uses must be in the lower 4GB. If not, then it won't work. Current does proper scatter/gather, so should work without issue. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Floating point in interrupt handler
In message: [EMAIL PROTECTED] Daan Vreeken [PA4DAN] [EMAIL PROTECTED] writes: : But what I haven't found is a description of exactly what the kernel is : missing to allow floating point operations to be done there. FPU context is assumed to only change in user processes. You'd have to fix the FPU state saving code to cope with it changing everywhere, or you'd have to explicitly put the goo to save/restore it around the FP you want to do in the kernel. You had also make sure that the floating point exceptions never trap, since trapping inside the kernel has very limited support. You'll have to fix the problems that this would cause, or force the FPU into a state where it never traps. Sure, maybe you can make it happen. However, you are in for much pain and suffering. The kernel isn't a general purpose computing environment, and trying to pretend it is will lead to suffering. Especially inside of an interrupt handler. It is less bad if this is an ithread, but could be quite painful if you want to do this inside of a fast interrupt handler to reduce latency. I'd recommend strongly against trying this and revaluate your true need for FP in the kernel. From your other mail, you don't seem open to this answer. If you don't take it, you are setting yourself up for a lot of pain and suffering. It is your choice, however. If you do manage to pull it of, I'd be very interested in see what things I didn't know to warn you about... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what happened to make world?
In message: [EMAIL PROTECTED] Pietro Cerutti [EMAIL PROTECTED] writes: : Max Laier wrote: : On Thursday 30 August 2007, Pietro Cerutti wrote: : # make world : WARNING: make world will overwrite your existing FreeBSD : installation without also building and installing a new : kernel. This can be dangerous. Please read the handbook, : 'Rebuilding world', for how to upgrade your system. : Define DESTDIR to where you want to install FreeBSD, : including /, to override this warning and proceed as usual. : You may get the historical 'make world' behavior by defining : HISTORICAL_MAKE_WORLD. You should understand the implications : before doing this. : : Bailing out now... : *** Error code 1 : : Stop in /usr/src. : : : Now, THIS is quite funny... do you really thing that a person with : - root access : - the knowledge of the existence of make world : needs this sort of things? : : I didn't see anything about this new-wave-of-user-friendly-bsd going on : the list.. have I missed something? : : And your complaint would be ... what exactly? : : : I don't want my OS to treat me like a stupid. I will note that since we switched to the multi-phase world with explicit reboot instructions, the support load for 'oh no, I shot myself in the foot' has gone way down. There are times that one must put a few safety rails in place. Since we have limited resources for support for users, it is better to make them make sure they know what they are doing so we can focus our resources better. Sometimes we have to optimize for developer time in the tradeoffs that are made. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device hints for isa modules
In message: [EMAIL PROTECTED] Constantine A. Murenin [EMAIL PROTECTED] writes: : Dear freebsd-hackers@, : : Is there a way to statically compile device hints into an isa(4) module? : : From what it looks, there is no place in the source tree to put the : hints for isa(4) modules -- you either have to place default hints into : GENERIC.hints, implying that the driver will be compiled into a GENERIC : kernel, or place it into NOTES. In the former case, having a module is : then useless; in the latter, the module simply ain't going to work. No. It isn't useless. If you have a driver listed in GENERIC.hints, but not GENERIC, then there's no driver that will be attached and the hint will effectively be ignored. If you later load a driver of the proper name, it will use the hints. We do this all the time at work so that we can load our drivers and have them probe/attach for the custom ISA hardware we produce (it doesn't do ISA PNP). You actually need to place them in both places. : This is complicated further by the fact that changing isa hints after : the boot has no effect on isa driver modules that use standard methods : of resource acquisition. (Specifically, notice that kenv(1) won't give : you an error message when you try to create a new hint or update an : existing one, and the new or updated hint will in fact be visible back : from kenv(1), but it won't have any effect on bus_alloc_resource(9) : calls, thus modules depending on isa hints will fail to find their : hardware.) This is actually a bug. It would be desirable to place hints into the hint space after boot. : I'm specifically looking for a solution to a usable module for my lm(4) : driver in soc2007/cnst-sensors perforce branch... Just add them to GENERIC.hints. Then if/when your driver is loaded, it will properly probe/attach. If it is never loaded, then there's no real harm. I have a kernel without sio. Yet I have the following hints: hint.sio.0.at=isa hint.sio.0.flags=0x10 hint.sio.0.irq=4 hint.sio.0.port=0x3F8 hint.sio.1.at=isa hint.sio.1.irq=3 hint.sio.1.port=0x2F8 hint.sio.2.at=isa hint.sio.2.disabled=1 hint.sio.2.irq=5 hint.sio.2.port=0x3E8 hint.sio.3.at=isa hint.sio.3.disabled=1 hint.sio.3.irq=9 hint.sio.3.port=0x2E8 The only side effect you'll see is with devinfo -v: nexus0 acpi0 pcib0 pnpinfo _HID=PNP0A03 _UID=1 at handle=\_SB_.PCI0 pci0 isab0 pnpinfo vendor=0x1002 device=0x4377 subvendor=0x subdevice=0x class=0x060100 at slot=20 function=3 handle=\_SB_.PCI0.LPC0 isa0 sio0 sio1 sio2 sio3 devinfo doesn't show it. kldstat on my box doesn't list any sio devices. When I load sio.ko, sio0-sio3 do not attach because I don't have any real COMx devices. This is a little confusing, but has proven to be fairly useful in practice. It would be a little nicer if devinfo -v reported if the device was attached or not... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: finished? porting ZyDAS zb1211/zb1211b driver for FreeBSD
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : On Sunday 05 August 2007, Weongyo Jeong wrote: : Hello, : : I just finished to port zyd(4) from NetBSD for FreeBSD and it works well in : my environment without any panic ;-) (In zb1211b, RF AL2230, open auth, : 54M). But It's not perfect and not be tested on another RF controllers and : not on zb1211. IMO, it would work too. : : A patch which is for CURRENT is available at : http://weongyo.org/patches/freebsd/if_zyd-CURRENT-20070805.diff : : Comments, questions and feedbacks always welcome. : : PS. special thanks to Pyun YongHyeon. : : Hi, : : Is it possible that you could spend some time porting your ZYD driver to the : HPS USB stack aswell ? Isn't zyd already in the hps stack? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] enhance powerd(8) to handle max temperature
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : Warner Losh wrote: : From: Nate Lawson [EMAIL PROTECTED] : Subject: Re: [patch] enhance powerd(8) to handle max temperature : Date: Thu, 02 Aug 2007 10:08:33 -0700 : : M. Warner Losh wrote: : I keep getting the system shutting down on my HP by FreeBSD because : the temperature exceeds the _CRT value. Maybe there's something wrong : with my values, since it happens a lot: : : hw.acpi.thermal.min_runtime: 0 : hw.acpi.thermal.polling_rate: 10 : hw.acpi.thermal.user_override: 0 : hw.acpi.thermal.tz0.temperature: 0.0C : hw.acpi.thermal.tz0.active: -1 : hw.acpi.thermal.tz0.passive_cooling: 1 : hw.acpi.thermal.tz0.thermal_flags: 0 : hw.acpi.thermal.tz0._PSV: 90.0C : hw.acpi.thermal.tz0._HOT: -1 : hw.acpi.thermal.tz0._CRT: 94.0C : hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 : : Note: temperature is always 0.0C. : : What can I do to help my situation, if I really want the kernel doing : the cooling? : Your embedded controller is timing out. Thus you're getting a bogus : value for _TMP. : : Those settings for _CRT appear correct. It's the measured temperature : that is wrong. : : So how do I track down the problem? I'm tired of the system just : shutting down when I'm building OOO or even something simpler like : doing a buildworld... : : You do what's #1 on my list, which is rewrite the EC driver event model : (yet again) and figure out if it's possible to automatically detect : which workarounds are needed. Linux requires you to specify boot-time : flags to select polled or event-driven work. Hmmm. OK. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] enhance powerd(8) to handle max temperature
In message: [EMAIL PROTECTED]
Alexandre \Sunny\ Kovalenko [EMAIL PROTECTED] writes:
: On Thu, 2007-08-02 at 10:08 -0700, Nate Lawson wrote:
: M. Warner Losh wrote:
: In message: [EMAIL PROTECTED]
: Nate Lawson [EMAIL PROTECTED] writes:
: : Hajimu UMEMOTO wrote:
: : On Mon, 30 Jul 2007 23:31:33 +0200
: : Pietro Cerutti [EMAIL PROTECTED] said:
: : gahr My patch is really just a first draft that I wrote in order to
have
: : gahr feedbacks on the general idea to implement a temperature
controlling
: : gahr system inside powerd, and doesn't implement hysteresis as you
noted, and
: : gahr your feedback is that it's not a good idea, which I respect.
: :
: : It is rather backward, IMHO. I did implement a passive cooling
: : feature as an enhancement of powerd(8) like you did, during initial
: : phases. Then, I implemented it in our kernel as a result.
: :
: : I'll take a look at your patch. Umemoto-san is right in that you really
: : want the kernel to control cooling. What happens if powerd dies/hangs
: : and your system burns up? Passive cooling is often a last resort to
: : keep the system from overheating.
:
: I keep getting the system shutting down on my HP by FreeBSD because
: the temperature exceeds the _CRT value. Maybe there's something wrong
: with my values, since it happens a lot:
:
: hw.acpi.thermal.min_runtime: 0
: hw.acpi.thermal.polling_rate: 10
: hw.acpi.thermal.user_override: 0
: hw.acpi.thermal.tz0.temperature: 0.0C
: hw.acpi.thermal.tz0.active: -1
: hw.acpi.thermal.tz0.passive_cooling: 1
: hw.acpi.thermal.tz0.thermal_flags: 0
: hw.acpi.thermal.tz0._PSV: 90.0C
: hw.acpi.thermal.tz0._HOT: -1
: hw.acpi.thermal.tz0._CRT: 94.0C
: hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1
:
: Note: temperature is always 0.0C.
:
: What can I do to help my situation, if I really want the kernel doing
: the cooling?
:
: Your embedded controller is timing out. Thus you're getting a bogus
: value for _TMP.
: I have sort of picked up this thread in the middle... was it determined
: that EC is timing out? The reason for asking is -- I used to have a
: laptop where _TMP would just read value from the memory location, which
: was never populated anywhere else in ASL. Call to _PSV method would go
: figure current temperature and start fan, if necessary. Ugly...
:
: Dumping ASL (using instructions from handbook) and looking for something
: like
:
: Method (_TMP, 0, NotSerialized)
:
: might be a real eye opener.
:
: If you would like me to take a look at your ASL, send it to me privately
: -- I've only done it for one laptop, so no claims of the great skill
: there, but maybe it is as simple as the other one ;)
Method (_TMP, 0, NotSerialized)
{
If (\_SB.PCI0.LPC0.ECOK ())
{
Multiply (\_SB.PCI0.LPC0.EC0.THEM, 0x0A, Local0)
Add (Local0, 0x0AAC, Local0)
Return (Local0)
}
Return (DTMP)
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] enhance powerd(8) to handle max temperature
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : Hajimu UMEMOTO wrote: : On Mon, 30 Jul 2007 23:31:33 +0200 : Pietro Cerutti [EMAIL PROTECTED] said: : gahr My patch is really just a first draft that I wrote in order to have : gahr feedbacks on the general idea to implement a temperature controlling : gahr system inside powerd, and doesn't implement hysteresis as you noted, and : gahr your feedback is that it's not a good idea, which I respect. : : It is rather backward, IMHO. I did implement a passive cooling : feature as an enhancement of powerd(8) like you did, during initial : phases. Then, I implemented it in our kernel as a result. : : I'll take a look at your patch. Umemoto-san is right in that you really : want the kernel to control cooling. What happens if powerd dies/hangs : and your system burns up? Passive cooling is often a last resort to : keep the system from overheating. I keep getting the system shutting down on my HP by FreeBSD because the temperature exceeds the _CRT value. Maybe there's something wrong with my values, since it happens a lot: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 0.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 90.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 94.0C hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 Note: temperature is always 0.0C. What can I do to help my situation, if I really want the kernel doing the cooling? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] enhance powerd(8) to handle max temperature
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : Garrett Cooper wrote: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Nate Lawson [EMAIL PROTECTED] writes: : : Hajimu UMEMOTO wrote: : : On Mon, 30 Jul 2007 23:31:33 +0200 : : Pietro Cerutti [EMAIL PROTECTED] said: : : gahr My patch is really just a first draft that I wrote in order : to have : : gahr feedbacks on the general idea to implement a temperature : controlling : : gahr system inside powerd, and doesn't implement hysteresis as : you noted, and : : gahr your feedback is that it's not a good idea, which I respect. : : : It is rather backward, IMHO. I did implement a passive cooling : : feature as an enhancement of powerd(8) like you did, during initial : : phases. Then, I implemented it in our kernel as a result. : : : I'll take a look at your patch. Umemoto-san is right in that you : really : : want the kernel to control cooling. What happens if powerd dies/hangs : : and your system burns up? Passive cooling is often a last resort to : : keep the system from overheating. : : I keep getting the system shutting down on my HP by FreeBSD because : the temperature exceeds the _CRT value. Maybe there's something wrong : with my values, since it happens a lot: : : hw.acpi.thermal.min_runtime: 0 : hw.acpi.thermal.polling_rate: 10 : hw.acpi.thermal.user_override: 0 : hw.acpi.thermal.tz0.temperature: 0.0C : hw.acpi.thermal.tz0.active: -1 : hw.acpi.thermal.tz0.passive_cooling: 1 : hw.acpi.thermal.tz0.thermal_flags: 0 : hw.acpi.thermal.tz0._PSV: 90.0C : hw.acpi.thermal.tz0._HOT: -1 : hw.acpi.thermal.tz0._CRT: 94.0C : hw.acpi.thermal.tz0._ACx: 40.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 : : Note: temperature is always 0.0C. : : What can I do to help my situation, if I really want the kernel doing : the cooling? : : Warner : : : Wow, something's really wrong with those calculated temperatures. At : that value most of the plastic and weaker circuitry should have fused : together =\. : : It would be interesting to see what the values are just after booting, : or even earlier if you can get the bios to give temperatures : (some MBs have that possibility) The values are always the same. ACx is always 40C -1 ... and temperature is always 0. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
In message: [EMAIL PROTECTED] Daniel Molina Wegener [EMAIL PROTECTED] writes: : : Hello, : :I need information about few things, I hope someone can help : me and thanks in advance. : : a) Is there any function or variable that tells me which is the :root user UID in the system, or root always have 0 and it's :an elegant option to compare the variables or structure :members against zero. The super user is always UID == 0. By definition. The root account typically is 0, but doesn't have to be. User accounts typically aren't 0, but can be (cf toor). Any account with a uid of 0 is a super user. It is the super user that gets all the toys. : b) Can normal users look for system processes or kernel threads? Sometimes. See the sysctls security.bsd.see_other_gids and security.bsd.see_other_uids. : c) Can root look for system processes or kernel threads? If it is the super user, yes. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
