Re: Usage of "files" for config
Srinivas, good day.
Tue, Oct 28, 2008 at 03:52:35AM +0530, Srinivas wrote:
> I would like to know the usage of files and files.[arch] in sys/conf.
> Basically, I didnt get the advantage of having a common file for
> compilation(like files) rather than an individual Makefile in each
> subdirectory.
'files' and 'files.$ARCH' are the input directives for the config(8)
utility. Makefile is produced with the help of these files. The
rationale for having 'files' and 'files.$ARCH' is simple: there are
platform-specific directives and common directives.
>
> I have read makefile(of mkmakefile.c in config). What is the usage of
> "standard", "optional" and "mandatory" and why it is followed by
> device.
Read comments from 'mkmakefile.c':
-
/*
* If an entry is marked "mandatory", config will abort if it's
* not called by a configuration line in the config file. Apart
* from this, the device is handled like one marked "optional".
*/
-
> What are .m files? What are they used for?
They define module interfaces and are processed by the AWK script
/sys/tools/makeobjops.awk. The output will be source and header files,
named .c and .h. You can do 'ls *_if.[ch]' in
the kernel build directory and examine some files to get a hint on
what's going on. M-files are processed with the help of
/sys/conf/kern.post.mk and /sys/conf/kmod.mk.
> Why are some of the rules in the generated makefile *.ln like scsi_all.ln?
These files are lint(1)'ed: see /sys/conf/kern.post.mk, search for
LNFILES.
> What is ${NORMAL_LINT} and ${NORMAL_C} in the generated makefile mean?
'make -V NORMAL_LINT' and 'make -V NORMAL_C' invoked from the kernel
compilation directory should tell you about the values of these
variables. They are defined by /sys/conf/kern.pre.mk, so you can
examine it as well.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpBOoMn3hgfL.pgp
Description: PGP signature
Re: [Testers wanted] /dev/console cleanups
Hello Carlos, * Carlos A. M. dos Santos <[EMAIL PROTECTED]> wrote: > The patched source builds and installs flawlessy. However I observed > something that seems to be a regression. If I run either xconsole or > xterm -C I only see kernel messages, even though my X startup (via > XDM) changes the owner of /dev/console to the logged-in user. I mean, > if I do some timg like "echo OK > /dev/console", the message is echoed > on /dev/ttyv0, not by xconsole > > This is the same problem reported by Jeff Blank on RELENG_7: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/044949.html > http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/045885.html It's nice to hear that the patch didn't break anything on your system. I hope to receive more reviews, but I think I'll just commit it this weekend (with small modifications). About the /dev/console issues: Robert Watson and I discussed this some time ago on IRC and what I did in HEAD (not RELENG_7) was that I changed TIOCCONS not to take a look at the permissions of /dev/console, but we changed it to use priv_check(). This means that right now you can only call TIOCCONS as root. I can't really understand why the problem exists on RELENG_7. About making xconsole setuid: I've read the messages you mentioned, but I think we could just alter console to call TIOCCONS and just drop privileges. An even better solution would be to just get rid of TIOCCONS and invent a better solution to capture syslog messages. I can't really understand why we want to abuse TTY's to do this. So I can't say we're working on this, but at least I can confirm the issue. -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://80386.nl/ pgpe3Z4oSjMVU.pgp Description: PGP signature
Re: Usage of "files" for config
Eygene, Your reply is very helpful. Thank you very much. On Tue, Oct 28, 2008 at 1:16 PM, Eygene Ryabinkin <[EMAIL PROTECTED]> wrote: >> I would like to know the usage of files and files.[arch] in sys/conf. >> Basically, I didnt get the advantage of having a common file for >> compilation(like files) rather than an individual Makefile in each >> subdirectory. > > 'files' and 'files.$ARCH' are the input directives for the config(8) > utility. Makefile is produced with the help of these files. The > rationale for having 'files' and 'files.$ARCH' is simple: there are > platform-specific directives and common directives. Still, I didnt get the purpose of having a common "files" file for the kernel to generate Makefile. I am trying to understand the advantage of this approach with the conventional way of having a makefile for each sub-directory(device or module) and recurse from top of kernel with a configuration file dictating what features need to be included in the kernel. Thanks, Srinivas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Usage of "files" for config
On Tuesday 28 October 2008 05:31:36 am Srinivas wrote: > Eygene, Your reply is very helpful. Thank you very much. > > On Tue, Oct 28, 2008 at 1:16 PM, Eygene Ryabinkin <[EMAIL PROTECTED]> wrote: > >> I would like to know the usage of files and files.[arch] in sys/conf. > >> Basically, I didnt get the advantage of having a common file for > >> compilation(like files) rather than an individual Makefile in each > >> subdirectory. > > > > 'files' and 'files.$ARCH' are the input directives for the config(8) > > utility. Makefile is produced with the help of these files. The > > rationale for having 'files' and 'files.$ARCH' is simple: there are > > platform-specific directives and common directives. > > Still, I didnt get the purpose of having a common "files" file for the > kernel to generate Makefile. > > I am trying to understand the advantage of this approach with the > conventional way of having a makefile for each sub-directory(device or > module) and recurse from top of kernel with a configuration file > dictating what features need to be included in the kernel. The usage of config goes back to BSD itself prior to FreeBSD for one. However, I find the 'files' format a lot easier to parse and work with then the mess of .ifdef's, etc. that would end up in 'kern/Makefile' for example. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RTLD changes for non-native system (was: Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?)
Quoting Daniel O'Connor <[EMAIL PROTECTED]> (from Tue, 28 Oct 2008 10:18:10 +1030): On Tuesday 28 October 2008 01:31:16 M. Warner Losh wrote: 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... Good point.. The problem is really the Linux linker - it will find a FreeBSD library and try and use it ahead of a Linux one later in the search path - this prevents stuff working :) I have this exact problem with libfontconfig and Xilinx ISE. Perhaps instead of ignore, use last.. But then it doesn't really matter for the FreeBSD linker - I imagine I would have to convince Linux folks it's a good idea. Please ignore for a moment that we are not talking about changing the FreeBSD RTLD anymore: Would it make sense (for us and/or for GNU) to first search for libs for the current system and if none are found to try the others? Bye, Alexander. -- There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
