Re: MacBookPro7,1 and FreeBSD 8.1
Hi. I think that I can broke my laptop %) I same found information about MacBook in the files: sys/dev/asmc/asmc.c sys/dev/asmc/asmcvar.h sys/dev/usb/input/atp.c I attached acpi dumps from this is how to http://www.projectosx.com/forum/index.php?showtopic=359 On Saturday 13 November 2010 13:40:24 Veniamin Gvozdikov wrote: Hello. I fund a few lines about the macbook but I have issue. if (strncmp(sysenv, "MacBook5,1", 10) == 0 || strncmp(sysenv, "MacBookPro5,5", 13) == 0 || strncmp(sysenv, "Macmini3,1", 10) == 0) strncmp(sysenv, "Macmini3,1", 10) == 0 || strncmp(sysenv, "iMac9,1", 7) == 0) I see for macbookpro5,5 value 13, where is can I found value for 7,1? 13 is the length of the string exluding the terminating zero. --HPS thank you! This might be because your model is not listed in a quirk-table: grep -ri macbook /usr/src/sys/amd64 /usr/src/sys/amd64/amd64/machdep.c --HPS ___ 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"
i386 specific manual pages
hi there,
could we please have the following manual pages
lib/libc/i386/sys/i386_get_ioperm.2
lib/libc/i386/sys/i386_get_ldt.2
lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?)
lib/libc/i386/sys/i386_vm86.2
installed into /usr/share/man/man{2,3}/i386? they can be accessed via
sysarch(2) and are explicitly being referenced by its manual page.
that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=amd64.
cheers.
alex
--
a13x
___
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"
WITH_GPIO and obsolete files
hi there,
this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not specified
in src.conf.
also i just noticed that src.conf needs to be regenerated, because it's missing
the
WITH_GPIO description.
cheers.
alex
--
a13x
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index 4ce9968..d9b4e35 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -808,6 +808,11 @@ OLD_FILES+=usr/lib32/libgpib_p.a
.endif
.endif
+.if ${MK_GPIO} == no
+OLD_FILES+=usr/sbin/gpioctl
+OLD_FILES+=usr/share/man/man8/gpioctl.8.gz
+.endif
+
.if ${MK_GSSAPI} == no
OLD_FILES+=usr/lib/libgssapi.a
OLD_FILES+=usr/lib/libgssapi.so
___
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: i386 specific manual pages
On Sun, Nov 14, 2010 at 01:55:59PM +, Alexander Best wrote:
> hi there,
>
> could we please have the following manual pages
>
> lib/libc/i386/sys/i386_get_ioperm.2
> lib/libc/i386/sys/i386_get_ldt.2
> lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?)
> lib/libc/i386/sys/i386_vm86.2
>
> installed into /usr/share/man/man{2,3}/i386? they can be accessed via
> sysarch(2) and are explicitly being referenced by its manual page.
>
> that way doing 'man -mi386 i386_get_ioperm' e.g. would work under arch=amd64.
Just a note: all of them except vm86 can be reasonably implemented on
amd64, as well are supported under ia32 emulation on amd64. I am not
sure that suggestion to do the work make sence, since they functions
looks unused even on i386.
pgpkrYxYN1pqf.pgp
Description: PGP signature
Re: i386 specific manual pages
On Sun Nov 14 10, Kostik Belousov wrote:
> On Sun, Nov 14, 2010 at 01:55:59PM +, Alexander Best wrote:
> > hi there,
> >
> > could we please have the following manual pages
> >
> > lib/libc/i386/sys/i386_get_ioperm.2
> > lib/libc/i386/sys/i386_get_ldt.2
> > lib/libc/i386/sys/i386_set_watch.3 (can this also be accessed?)
> > lib/libc/i386/sys/i386_vm86.2
> >
> > installed into /usr/share/man/man{2,3}/i386? they can be accessed via
> > sysarch(2) and are explicitly being referenced by its manual page.
> >
> > that way doing 'man -mi386 i386_get_ioperm' e.g. would work under
> > arch=amd64.
>
> Just a note: all of them except vm86 can be reasonably implemented on
> amd64, as well are supported under ia32 emulation on amd64. I am not
> sure that suggestion to do the work make sence, since they functions
> looks unused even on i386.
i'm afraid we don't agree on that issue. i need to set io permissions in order
to write to the parallel port and don't want to open /dev/io for security
reasons. right now i don't know any way of doing this under amd64 except by
using sysarch(2). it might be possible to implement this natively under amd64,
but that is not the point. sysarch(2) is available *now* and i should be able
to get information about the architecture-dependent functions i can use with
sysarch(2).
if a native silution for amd64 pops up in the future that's great, but there's
no point in installing the sysarch(2) manual and referencing the i386
architecture-dependent functions in it without providing necessary information
to use those functions.
thats like buying a car and the guy is telling you "it has lots of cool
features". when you ask him however "what are those features" he replies:
"well. be sure it has a lot of features, however i can't tell you what they
are". ;)
cheers.
alex
--
a13x
___
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: The path is now set for "busybox", FreeBSD style
Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > I've committed the below changes to -HEAD. You can now create and build your > own busybox style binary system, completely cross-compiled within the > existing Make framework. It isn't as impressive as it sounds though - a lot > of the framework is already there from just building crunchgen'ed > rescue/sysinstall binaries. > > There's a few things which should be done. Specifically, being able to build > an alternative set of libraries before building the crunchgen target. The > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, etc > but you may not want your crunch'ed image to have them. To do this right > now, you have to disable these features in the main build. That may be OK > for some. > > But just to stress it - I've got a couple of access point images at home > running a crunchgen'ed environment under MIPS and besides the obvious binary > bloat, it works perfectly well. Besides a cut-down startup framework, the > image cross-builds entirely from the base FreeBSD source tree. > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > Makefile scripts online to try. That's great. I assume it be not be hard for someone to take your scripts as a starting point and create a sysutils/bsdbox akin to sysutils/busybox? ___ 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: Deterministic builds?
Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas: >> >> Since the SVN rev. is recorded, I think a timestamp is redundant. Any >> ideas where I can disable the timestamps in the source? > > The timestamp is not 'redundant'. It records _when_ you compiled the > sources of the kernel, which in itself is a useful bit of information. I'm curious as to why this might be useful? Would the mtime of the file not be be sufficient? I can only think of debugging purposes, but apart from the timestamp, two kernels with the same rev. would be bitwise identical, so I think the rev. number is more useful. Is the timestamp not just a remnant from the CVS days? If it is useful, why not brand all binaries with a rev. number and a timestamp? Erik
Re: Deterministic builds?
On 2010-11-14 21:22, Erik Cederstrand wrote: I'm curious as to why this might be useful? Would the mtime of the file not be be sufficient? I can only think of debugging purposes, but apart from the timestamp, two kernels with the same rev. would be bitwise identical, This does not have to be the case. For example, if you have have local modifications, or use different settings in make.conf or src.conf. Similarly, the host on which something is built can be interesting metadata, because not all hosts are equal. If it is useful, why not brand all binaries with a rev. number and a timestamp? There are compilers that automatically brand every binary with a "built on" timestamp. If you want to 'compare' such binaries, you simply need a tool that disregards the timestamps. ___ 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: Deterministic builds?
Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: > On 2010-11-14 21:22, Erik Cederstrand wrote: >> I'm curious as to why this might be useful? Would the mtime of the >> file not be be sufficient? I can only think of debugging purposes, but >> apart from the timestamp, two kernels with the same rev. would be >> bitwise identical, > > This does not have to be the case. For example, if you have have local > modifications, or use different settings in make.conf or src.conf. In this case the timestamp + rev. is not sufficient to reproduce the kernel anyway. You'd need to store externally the non-standard contents of conf files, local diffs etc. on all your non-standard builds. You could do all sorts of fun stuff, even fool the rev. number or timestamp if you wanted. I'm just saying that for the standard user on a standard GENERIC kernel (and world for that matter) - the revision number should be sufficient for e.g. filing a PR. If you need the timestamp, there's the mtime. Erik
Re: Deterministic builds?
On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote: > > Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: > > > On 2010-11-14 21:22, Erik Cederstrand wrote: > >> I'm curious as to why this might be useful? Would the mtime of the > >> file not be be sufficient? I can only think of debugging purposes, but > >> apart from the timestamp, two kernels with the same rev. would be > >> bitwise identical, > > > > This does not have to be the case. For example, if you have have local > > modifications, or use different settings in make.conf or src.conf. > > In this case the timestamp + rev. is not sufficient to reproduce the kernel > anyway. You'd need to store externally the non-standard contents of conf > files, local diffs etc. on all your non-standard builds. You could do all > sorts of fun stuff, even fool the rev. number or timestamp if you wanted. > > I'm just saying that for the standard user on a standard GENERIC kernel (and > world for that matter) - the revision number should be sufficient for e.g. > filing a PR. If you need the timestamp, there's the mtime. It might not be very easy, going from revision to timestamp. It is still very useful to know the rough timeframe when a kernel was built, as that might give you the "age" of the source tree. This is of course not a very good mapping, and the reason we have both the revision number in there, but also something a human understands. If this timestamp must be fixed, my vote would be on using the timestamp of the svn revision the build was using as a source. But it should be made clear, that this is then no longer the built timestamp, but the source repo timestamp. Uli smime.p7s Description: S/MIME cryptographic signature
Re: Deterministic builds?
On Sun, 14 Nov 2010 21:22:53 +0100, Erik Cederstrand wrote: >Den 12/11/2010 kl. 21.20 skrev Giorgos Keramidas: >>> Since the SVN rev. is recorded, I think a timestamp is redundant. Any >>> ideas where I can disable the timestamps in the source? >> >> The timestamp is not 'redundant'. It records _when_ you compiled the >> sources of the kernel, which in itself is a useful bit of information. > > I'm curious as to why this might be useful? Would the mtime of the file > not be be sufficient? I can only think of debugging purposes, but apart > from the timestamp, two kernels with the same rev. would be bitwise > identical, so I think the rev. number is more useful. Is the timestamp > not just a remnant from the CVS days? The timestamp is a remnant from much older days, but it's still a bit useful if you build several kernels from 'almost' the same source tree. For example, think of two kernels who are built from the same svn revision but they are built from two different patched kernel source trees. They will both have a version string that says "svn 12345+" but their "+" will refer to different patch states. When a kernel developer is trying various iterations of this own local patch, having the timestamp may actually be useful to differentiate between a working and a non-working patch state. I *like* the idea of 100% repeatable kernel builds and I'd even go as far as suggesting it is nice to turn on by *default*, but let's think about a way to _include_ the timestamp e.g. with an src.conf option for those cases when it's really useful. pgpn7MvxgD8SB.pgp Description: PGP signature
Re: WITH_GPIO and obsolete files
On 2010-11-14, at 6:27 AM, Alexander Best wrote: > hi there, > > this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not specified > in src.conf. > > also i just noticed that src.conf needs to be regenerated, because it's > missing the > WITH_GPIO description. Thanks Alexander, I commited this patch and regenerated src.conf.5 manpage. -- gonzo ___ 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: WITH_GPIO and obsolete files
On Sun Nov 14 10, Oleksandr Tymoshenko wrote: > > On 2010-11-14, at 6:27 AM, Alexander Best wrote: > > > hi there, > > > > this patch will remove gpioctl and gpioctl.8 when WITH_GPIO was not > > specified > > in src.conf. > > > > also i just noticed that src.conf needs to be regenerated, because it's > > missing the > > WITH_GPIO description. > Thanks Alexander, I commited this patch and regenerated src.conf.5 > manpage. thanks. :) > > > -- > gonzo > > -- a13x ___ 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] More explicit return codes for sigismember(3)
Hi, I found this change kicking around my tree from a while back. It brings the manpage for sigismember(3) more in line with the POSIX definition [1] in the RETURN CODES section by explicitly noting that sigismember(3) returns 0 if a signal is valid and not a part of the set passed in. If someone could review and commit the change, it would be much appreciated. Thanks! -Garrett [1] http://www.opengroup.org/onlinepubs/009695399/functions/sigismember.html (SUS Issue 6 -- but the wording for the manpage is the same in SUS Issue 7). more-explicit-sigismember-return-codes.diff Description: Binary data ___ 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] Fix lib/libpam's include of sys/time.h
libpam uses sys/time.h to pick up ctime, but it's actually defined in time.h according to POSIX and the ctime manpage. If someone could help review and commit this patch, it would be much appreciated. This is part of a much larger change to fix namespace pollution with time.h in sys/time.h. Thanks, -Garrett Index: lib/libpam/modules/pam_unix/pam_unix.c === --- lib/libpam/modules/pam_unix/pam_unix.c (revision 215333) +++ lib/libpam/modules/pam_unix/pam_unix.c (working copy) @@ -39,7 +39,6 @@ #include #include -#include #include #include @@ -50,6 +49,7 @@ #include #include #include +#include #include #include ___ 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] Fix lib/libpam's include of sys/time.h
On Sun, Nov 14, 2010 at 9:14 PM, Garrett Cooper wrote: > libpam uses sys/time.h to pick up ctime, but it's actually defined > in time.h according to POSIX and the ctime manpage. > If someone could help review and commit this patch, it would be > much appreciated. This is part of a much larger change to fix > namespace pollution with time.h in sys/time.h. Sorry... missed the gettimeofday requirement in the lib. The library fully compiles with this patch (where sys/time.h isn't removed). This is POSIX compliant. Thanks, -Garrett Index: /usr/src/lib/libpam/modules/pam_unix/pam_unix.c === --- /usr/src/lib/libpam/modules/pam_unix/pam_unix.c (revision 215333) +++ /usr/src/lib/libpam/modules/pam_unix/pam_unix.c (working copy) @@ -50,6 +50,7 @@ #include #include #include +#include #include #include ___ 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"
