Re: System Drops to manual mount root prompt after HDD duplication
David Cramblett [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: What's in your /boot.config and /boot/loader.conf? I have no boot.config. [EMAIL PROTECTED] /]# cat /boot/loader.conf # -- sysinstall generated deltas -- # userconfig_script_load=YES Beats me... I can't even remember what userconfig_script is supposed to do. Note that support for 5.2.1 ended on July 31, 2004. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On May 14, 2007, at 10:03 PM, Garrett Cooper wrote: Bert JW Regeer wrote: On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a écrit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. What is the reason to use SQL-based database? You'll perform direct queries to database? The packaging system is for ordinal users, not sql geeks, so they should not have to use sql for managing packages. So a simple set of hashes will suffer or needs. I agree with Julian that we should have a backup of packaging database in plain text format, and utility to rebuild it. This way we can always restore the database if something goes wrong. Furhtermore, that should not make a great impact on performance, since we don't have to rebuild it every day. I agree with Stan ;) fast and improved package utilities uses mainly some indexed berkeley DB combined with flat files, aren't they? I, and may be many other FreeBSD users use light systems for efficiency and easier management, if we use some database system it will require Disk Space, resources for the DB to run, dependencies and so on... And we also may be exposed to a that DB is better war ;) SQLite is compiled inside a program, and as such does not require any resources other than one file handle and some CPU time when querying. The file is stored on disk, and requires no separate process to be running to query. Maybe I misunderstood what you were trying to say. SQLite will require less resources than flat text files, since SQLite is a one time open then process, instead of what is currently happening, having to open and close hundreds of files depending on how many ports are installed. With this regard, SQLite is like BDB. Where SQLite uses standards compliant SQL statements to get data. Correct. From what I was reading shared memory read access and locking are two available features of BDB databases. The only thing is that I do agree that there should be a dumping and importing mechanism of some kind for semi-formatted text files, for backup, debugging, and modification purposes. That's just my personal idea on the topic though :). -- Stanislav Sedov ST4096-RIPE I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. In a world where hard drives are becoming more reliable, and are automatically relocating sectors that go bad, do we really have to worry about database corruption as much? I feel that many of the fears that are being put forward will do harm to a text based storage system as well. If one block drops out, it can cause tools to not be able to parse the files. Create a backup copy of the database after each successful transaction? There are ways to battle data corruption. True. I was thinking of backup, and recreation from scratch, considering that the database wouldn't be more than a few megs. In place replacement just seems like a hairy situation sometimes.. Using BDB is not an real option either. I can not even count the amount of times that the BDB database that portupgrade created has become corrupt because I accidently ran two portupgrades at the same time, or even remembered that I did not want to upgrade something and hit Ctrl+C. I'm sorry but nothing's completely solid in that respect, AFAIK. In terms of the first problem you mentioned, Wade is working on the locking http://wiki.freebsd.org/WadeWesolowsky. In terms of transactions, maybe we should take a look at Subversion for inspiration: http://svn.haxx.se/dev/ archive-2005-03/0301.shtml. I'm a firm believer that it's easier to incorporate code than it is to remove it. I am unable to see any references to transaction support for BDB databases, maybe I am missing something. Subversion in that thread is suggesting SQL for a totally different reason. fsfs is what most people are using as a subversion backend to help avoid BDB corruption. From the many people I have talked to that used to use Subversion with BDB have had major issues, whereas fsfs has not had any issues at all. Just what I have experienced myself as a Subversion
Re: Writing a plain text file to disk from kernel space
Hello Lawrence, in file kern/vfs_syscalls.c you can see the kern_open function that uses vn_open to open a file/vnode. There are more vn_* functions like vn_rdwr for reading and writing to a vnode or vn_close to close a vnode. To see how theses functions work, I suggest you grep for them in the kernel-files. BTW, you can get an thread-struct pointer from curthread (c.f. sys/pcpu.h). HTH, Marc Lörner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Berkeley DB API [was Re: SoC]
On Monday, 14 May 2007 at 21:42:18 -0700, Garrett Cooper wrote: Duane Whitty wrote: [snipped] I wonder what the ramifications of the above are to the goal of using the bdb in our base system to add db smarts to the pkg_install tools in a way that will be complementary to exising tools? Duane BDB-1 is an available option actually with the ruby tools. Try make config in the ports-mgmt/portupgrade directory. Excellent, I just checked. That's great. I was worried for about a second :) I never thought to check that out, sure glad you did! Duane [more snipped] -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Drops to manual mount root prompt after HDD duplication
On Tue, May 15, 2007 at 08:20:09AM +0200 I heard the voice of Dag-Erling Smørgrav, and lo! it spake thus: David Cramblett [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: What's in your /boot.config and /boot/loader.conf? I have no boot.config. [EMAIL PROTECTED] /]# cat /boot/loader.conf # -- sysinstall generated deltas -- # userconfig_script_load=YES Beats me... I can't even remember what userconfig_script is supposed to do. Note that support for 5.2.1 ended on July 31, 2004. Neither can I, but last weekend I upgraded some 4.x boxes to 5.x and then 6.x, and with the 5.x loader they croaked before booting until I took those userconfig_script_load lines out. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
On Mon, 2007-05-14 at 22:17 -0700, Garrett Cooper wrote: Ruby's nice, but it's built on Perl so I have suspicions on its overall usability / speed given my experience with Perl over the past 4 months daily for work :(.. Ruby's just the new big thing for programming languages, so everyone's into it. Kind of like how Java was compared to C/C++ a few years back. But once everything dies down people will realize that they'll still have to program in C/C++/Perl for real-world applications. Python seems better than Ruby from what I can see, but I really don't like the mandatory indentation thing. Ew.. Rubies are better Perls. That's the only connection between the two. One day, a Japanese programmer got fed up with Perl, and wrote a better language (for varying meanings of better). Its not based or built on Perl in any respect. Python and Ruby both have the same targets; to speed development time and increase programmer productivity. signature.asc Description: This is a digitally signed message part
Re: SoC
Tom Evans wrote: On Mon, 2007-05-14 at 22:17 -0700, Garrett Cooper wrote: Ruby's nice, but it's built on Perl so I have suspicions on its overall usability / speed given my experience with Perl over the past 4 months daily for work :(.. Ruby's just the new big thing for programming languages, so everyone's into it. Kind of like how Java was compared to C/C++ a few years back. But once everything dies down people will realize that they'll still have to program in C/C++/Perl for real-world applications. Python seems better than Ruby from what I can see, but I really don't like the mandatory indentation thing. Ew.. Rubies are better Perls. That's the only connection between the two. One day, a Japanese programmer got fed up with Perl, and wrote a better language (for varying meanings of better). Its not based or built on Perl in any respect. Python and Ruby both have the same targets; to speed development time and increase programmer productivity. But one must make a Perl before one can make a Ruby. Maybe that was what I was trying to aim for. Ruby's nice, but it seems like it's going to be a bit passe in a few years like Java was for compilable / interpretable languages. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
Garrett Cooper wrote: Tom Evans wrote: On Mon, 2007-05-14 at 22:17 -0700, Garrett Cooper wrote: Ruby's nice, but it's built on Perl so I have suspicions on its overall usability / speed given my experience with Perl over the past 4 months daily for work :(.. Ruby's just the new big thing for programming languages, so everyone's into it. Kind of like how Java was compared to C/C++ a few years back. But once everything dies down people will realize that they'll still have to program in C/C++/Perl for real-world applications. Python seems better than Ruby from what I can see, but I really don't like the mandatory indentation thing. Ew.. Rubies are better Perls. That's the only connection between the two. One day, a Japanese programmer got fed up with Perl, and wrote a better language (for varying meanings of better). Its not based or built on Perl in any respect. Python and Ruby both have the same targets; to speed development time and increase programmer productivity. But one must make a Perl before one can make a Ruby. Maybe that was what I was trying to aim for. Ruby's nice, but it seems like it's going to be a bit passe in a few years like Java was for compilable / interpretable languages. -Garrett Sorry for all you Java lovers out there.. it's just that from where I'm at I don't see anyone using it in the workplace (Intel). We're all using C/C++/Perl, with occasional spots of Ruby/Python. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Multiple IP Jail's patch for FreeBSD 6.2
Julian Elischer wrote on Monday, May 14, 2007 11:05 PM: Andre Oppermann wrote: Julian Elischer wrote: talk with Marko Zec about immunes. http://www.tel.fer.hr/zec/vimage/ and http://www.tel.fer.hr/imunes/ It has a complete virtualized stack for each jail. ipfw, routing table, divert sockets, sysctls, statistics, netgraph etc. Like I said there is a place for both approaches and they are complementary. A couple of hosting ISPs I know do not want to give a full virtualized stack to their customers. They want to retain full control over the network configuration inside and outside of the jail. In those (mass-hosting) cases it is done that way to ease support (less stuff users can fumble) and to properly position those products against full virtual machines and dedicated servers. Something like this: jail vimage virtual machine dedicated server. He as a set of patches against 7-current that now implements nearly all the parts you need. It Will be discussed at the devsummit on Wed/Thurs and we'll be discussing whether it is suitable for general inclusion or to be kept as patches. Note, it can be compiled out, which leaves a pretty much binarily compatible OS, so I personally would like to see it included. I don't think it is mature enough for inclusion into the upcoming 7.0R. Not enough integration time. Food for FreeBSD 8.0. Actually I am not sure I completely agree. Consider: Me neither. Markos work started at 4.0 already, which is a *long* time ago, so I would assume a decent level of maturity in the first place. I might add that What Marco has now is very functional and that people should kick its tires (tyres) a bit.. Yep. Also, having this functionality would give us sort of a unique feature over the competition. Helge Atos Origin GmbH, Theodor-Althoff-Str. 47, D-45133 Essen, Postfach 100 123, D-45001 Essen Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, www.atosorigin.de Dresdner Bank AG, Hamburg: Kto. 0954411200, BLZ 200 800 00, Swift Code DRESDEFF200, IBAN DE6920080954411200 Geschäftsführer: Dominique Illien, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: DE147861238 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Drops to manual mount root prompt after HDD duplication
Matthew D. Fuller [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Beats me... I can't even remember what userconfig_script is supposed to do. Note that support for 5.2.1 ended on July 31, 2004. Neither can I, but last weekend I upgraded some 4.x boxes to 5.x and then 6.x, and with the 5.x loader they croaked before booting until I took those userconfig_script_load lines out. Ooh, now I remember; userconfig was the old hardware configuration mechanism we had before device.hints. If you typed -c at the boot1 prompt, you would get an interactive display where you could assign IRQs and ports to devices. The script is basically a sequence of userconfig commands; you could extract it from kenv after an interactive boot and store it in a file which the loader would read the next time around. AFAIR, userconfig was axed between FreeBSD 3 and 4, so there would be no point in loading a userconfig script for a 5.x kernel. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On 2007-May-14 09:36:52 -0400, Mike Meyer [EMAIL PROTECTED] wrote: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. -- Peter Jeremy pgpner2BNNlNi.pgp Description: PGP signature
Re: Writing a plain text file to disk from kernel space
Lawrence Stewart [EMAIL PROTECTED] writes: I'm in the process of writing a kernel module to instrument some parts of the network stack in FreeBSD 6.2. Everything works perfectly, except that writing the logging info to syslog using printf is too inefficient for this particular task. Given that log messages need to be generated for each packet entering/leaving the network stack, my testing thus far has showed that syslog groans under the load and uses far too much CPU time. So, I'm looking for a way to manually open up a file from within kernel space and dump characters into it. Look at the ktrace code. Note that it opens the file in userland and passes it down to the kernel. You may want to consider a similar mechanism. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
Peter Jeremy [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. It would, if it were true. It isn't. apt-get --build source package_name DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a plain text file to disk from kernel space
Hi Marc, Marc Lörner wrote: [snip] BTW, you can get an thread-struct pointer from curthread (c.f. sys/pcpu.h). [snip] Thanks very much for the reply. curthread is the missing key that I've been looking for! Thank you so much. I've been banging my head against a brick wall for days now. I'll have a play around and report back to the list what I find for archival purposes. Cheers, Lawrence PS Just found a thread I hadn't found before (http://lists.freebsd.org/pipermail/freebsd-hackers/2006-March/015647.html) which has lots of useful info and a link (http://people.freebsd.org/~pjd/misc/kernio/) to some sample code! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD packaging system
Throwing caution to the wind and speaking without thinking about what was being said on Tue, May 15, 2007 at 12:00 , [EMAIL PROTECTED] blurted this: [much text deleted as I only am going to comment on one part - wjv] Message: 6 Date: Mon, 14 May 2007 23:34:52 -0700 From: Bert JW Regeer [EMAIL PROTECTED] Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) To: Garrett Cooper [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org On May 14, 2007, at 10:03 PM, Garrett Cooper wrote: Bert JW Regeer wrote: On May 12, 2007, at 5:14 AM, Philippe Laquet wrote: Stanislav Sedov a ?crit : On Fri, 11 May 2007 02:10:05 +0200 Ivan Voras [EMAIL PROTECTED] mentioned: - I think it's time to give up on using BDB+directory tree full of text files for storing the installed packages database, and I propose all of this be replaced by a single SQLite database. SQLite is public domain (can be slurped into base system), embeddable, stores all data in a single file, lightweight, fast, and can be used to do fancy things such as reporting. ... I am able to understand many of the gripes with using a databases, and have to import yet another code base into the FreeBSD base, however as one of the young ones, and knowing sed/awk/grep and SQL, I prefer SQL over having to process hundreds of text files using text processing tools. It saddens me each time I run one of the pkg_* tools that needs to parse the flat file structure since it takes so long. I have friends running Ubuntu and their apt-get returns results much faster. True. I was thinking of backup, and recreation from scratch, considering that the database wouldn't be more than a few megs. In place replacement just seems like a hairy situation sometimes.. ... The experience I got from running SVN with BDB as the back-end database to store my data, I say no thanks. In that case I would much rather stick with the flat text files than go with a database. Well, a few comments: -Text files are bloated. Although many people are for XML, it takes much longer to parse than binary databases. /var/db/pkg/ are all plain flat text files. I am not a supporter of XML at all. -Custom text files require custom format capable parsers, no matter what the format, and the less coverage a parser has, the more probable the likelihood of bugs IMO. We already have these in the pkg_* functions, so i'd hope they are fairly solid! ... I am not opposed to text files, other than that they can be slow. I am against BDB because over the years, in my experience they have shown to be extremely unreliable and easily corrupted. If we are going to be making changes to the way the ports/packages store the information about what exists, it should be done in such a way that it is scalable and at the same time extensible (is this a word?). So why not take the same approach that is used in the password and shadow files. That way you have a plain text editable file which then builds the pwd.db and spwd.db files that are used by the system. Or am I missing something there. Bert JW Regeer Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
issue with net/if_ppp.h
Hi guys
doing a test just like the way cmake do it to find includes on the system
##test.c##
#include net/if_ppp.h
int main(){return 0;}
i got the following output:
gcc test.c
In file included from /usr/include/net/if_ppp.h:28,
from test.c:1:
/usr/include/net/ppp_defs.h:86: error: syntax error before ext_accm
/usr/include/net/ppp_defs.h:146: error: syntax error before time_t
In file included from /usr/include/net/if_ppp.h:29,
from test.c:1:
/usr/include/net/if.h:265: error: field `ifru_addr' has incomplete type
/usr/include/net/if.h:266: error: field `ifru_dstaddr' has incomplete type
/usr/include/net/if.h:267: error: field `ifru_broadaddr' has incomplete type
/usr/include/net/if.h:299: error: field `ifra_addr' has incomplete type
/usr/include/net/if.h:300: error: field `ifra_broadaddr' has incomplete type
/usr/include/net/if.h:301: error: field `ifra_mask' has incomplete type
/usr/include/net/if.h:368: error: field `addr' has incomplete type
/usr/include/net/if.h:369: error: field `dstaddr' has incomplete type
test.c:7:2: warning: no newline at end of file
this test works on on Linux systems.
does anybody knows if this is a bug or problem with the net/if_ppp.h header?
thanks in advance
Manolito
--
Todo lo puedo en Cristo que me fortalece
Filipenses. 4:13
-
I can do all things through Christ who strengthens me.
Philippians 4:13
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
Garrett Cooper wrote: Tom Evans wrote: On Mon, 2007-05-14 at 22:17 -0700, Garrett Cooper wrote: Ruby's nice, but it's built on Perl so I have suspicions on its overall usability / speed given my experience with Perl over the past 4 months daily for work :(.. Ruby's just the new big thing for programming languages, so everyone's into it. Kind of like how Java was compared to C/C++ a few years back. But once everything dies down people will realize that they'll still have to program in C/C++/Perl for real-world applications. Python seems better than Ruby from what I can see, but I really don't like the mandatory indentation thing. Ew.. Rubies are better Perls. That's the only connection between the two. One day, a Japanese programmer got fed up with Perl, and wrote a better language (for varying meanings of better). Its not based or built on Perl in any respect. Python and Ruby both have the same targets; to speed development time and increase programmer productivity. But one must make a Perl before one can make a Ruby. Maybe that was what I was trying to aim for. Ruby's nice, but it seems like it's going to be a bit passe in a few years like Java was for compilable / interpretable languages. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Where did you find you need perl to build ruby. Its a separate thing all together. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: issue with net/if_ppp.h
* Manolo Valdes [EMAIL PROTECTED] wrote: In file included from /usr/include/net/if_ppp.h:28, from test.c:1: /usr/include/net/ppp_defs.h:86: error: syntax error before ext_accm /usr/include/net/ppp_defs.h:146: error: syntax error before time_t In file included from /usr/include/net/if_ppp.h:29, from test.c:1: /usr/include/net/if.h:265: error: field `ifru_addr' has incomplete type /usr/include/net/if.h:266: error: field `ifru_dstaddr' has incomplete type /usr/include/net/if.h:267: error: field `ifru_broadaddr' has incomplete type /usr/include/net/if.h:299: error: field `ifra_addr' has incomplete type /usr/include/net/if.h:300: error: field `ifra_broadaddr' has incomplete type /usr/include/net/if.h:301: error: field `ifra_mask' has incomplete type /usr/include/net/if.h:368: error: field `addr' has incomplete type /usr/include/net/if.h:369: error: field `dstaddr' has incomplete type Use the following lines: #include sys/types.h #include sys/socket.h #include net/if_ppp.h Yours, -- Ed Schouten [EMAIL PROTECTED] WWW: http://g-rave.nl/ pgpr1ufb9ScJO.pgp Description: PGP signature
Re: issue with net/if_ppp.h
El Tuesday 15 May 2007 10:05:35 am Daniel Molina Wegener escribió: El Mar, 15 de Mayo de 2007, 9:55, Manolo Valdes escribió: Hi guys Hello... doing a test just like the way cmake do it to find includes on the system Grat tool, I use cmake too... does anybody knows if this is a bug or problem with the net/if_ppp.h header? No, if_ppp requires other headers, I'm far from my BSD system, but you must look which header you must include before the if_ppp hreader. yes i thought so. But the cmake check_include_files(net/if_ppp.h HAVE_NET_IF_PPP_H) only test the header using the former test.c so i guest it is a cmake issue. i'll keep searching :) thanks Manolito -- Todo lo puedo en Cristo que me fortalece Filipenses. 4:13 - I can do all things through Christ who strengthens me. Philippians 4:13 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: issue with net/if_ppp.h
El Mar, 15 de Mayo de 2007, 9:55, Manolo Valdes escribió:
Hi guys
Hello...
doing a test just like the way cmake do it to find includes on the system
Grat tool, I use cmake too...
##test.c##
#include net/if_ppp.h
int main(){return 0;}
i got the following output:
gcc test.c
In file included from /usr/include/net/if_ppp.h:28,
from test.c:1:
/usr/include/net/ppp_defs.h:86: error: syntax error before ext_accm
/usr/include/net/ppp_defs.h:146: error: syntax error before time_t
In file included from /usr/include/net/if_ppp.h:29,
from test.c:1:
/usr/include/net/if.h:265: error: field `ifru_addr' has incomplete type
/usr/include/net/if.h:266: error: field `ifru_dstaddr' has incomplete type
/usr/include/net/if.h:267: error: field `ifru_broadaddr' has incomplete type
/usr/include/net/if.h:299: error: field `ifra_addr' has incomplete type
/usr/include/net/if.h:300: error: field `ifra_broadaddr' has incomplete type
/usr/include/net/if.h:301: error: field `ifra_mask' has incomplete type
/usr/include/net/if.h:368: error: field `addr' has incomplete type
/usr/include/net/if.h:369: error: field `dstaddr' has incomplete type
test.c:7:2: warning: no newline at end of file
this test works on on Linux systems.
does anybody knows if this is a bug or problem with the net/if_ppp.h header?
No, if_ppp requires other headers, I'm far from my BSD system,
but you must look which header you must include before the if_ppp
hreader.
thanks in advance
Manolito
[SNIP]
Regards,
--
.O. | Daniel Molina Wegener | C/C++ Developer
..O | dmw [at] unete [dot] cl | FOSS Coding Adict
OOO | BSD Linux User| Standards Rocks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: issue with net/if_ppp.h
On Tue, May 15, 2007 at 09:55:40AM -0400, Manolo Valdes wrote:
Hi guys
doing a test just like the way cmake do it to find includes on the system
##test.c##
#include net/if_ppp.h
int main(){return 0;}
What exactly are you trying to do here? This is not how you write C
software. You're missing quite a lot of other (standard) #includes,
which is why you're seeing the errors you are.
this test works on on Linux systems.
That's nice.
does anybody knows if this is a bug or problem with the net/if_ppp.h header?
It's a bug in your .c file, yes. :-)
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
In [EMAIL PROTECTED], Dag-Erling Smørgrav [EMAIL PROTECTED] typed: Peter Jeremy [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. It would, if it were true. It isn't. Except it is. apt-get --build source package_name That doesn't update from sources, that just builds a package. You're still stuck updating from packages. Further, like the rpm command, this doesn't deal with dependencies, other than to complain if they aren't met. This means that using it to deal with sources is about as pleasant as using rpm to install binary packages. Further, there doesn't appear to be anything like make.conf to make it easy to tailor the build process to meet the users requirements. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On Tue, 2007-05-15 at 11:23 -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Dag-Erling Smørgrav [EMAIL PROTECTED] typed: Peter Jeremy [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. It would, if it were true. It isn't. Except it is. apt-get --build source package_name That doesn't update from sources, that just builds a package. You're still stuck updating from packages. Further, like the rpm command, this doesn't deal with dependencies, other than to complain if they aren't met. This means that using it to deal with sources is about as pleasant as using rpm to install binary packages. Further, there doesn't appear to be anything like make.conf to make it easy to tailor the build process to meet the users requirements. mike Of course Gentoo does do this [updating from source], being as it is a rip-off of freebsd ports. I haven't used it since the (fairly) early days when portage was written as a series of bash scripts. I'm fairly sure they must have improved it since then - it made portupgrade look positively snappy. Unsurprisingly, everything was/is controlled by adding options (mainly USE_FLAGS - eg '+gtk2 -kde') to make.conf. Tom signature.asc Description: This is a digitally signed message part
Re: ioctl
On Monday 14 May 2007 15:28 Dag-Erling Smørgrav wrote:
Mohsen Pahlevanzadeh [EMAIL PROTECTED] writes:
Our FreeBSD is 4.11 because we can't use another version.
In that case, we can't help you.
Maybe he still has a chance. The following works on FreeBSD 4.9 for ATA
devices. I could only test it with an ATA CDROM, but here's the output:
Model:CD-224E
Revision: 1.9A
Serial:
#include stdio.h
#include strings.h
#include stdlib.h
#include fcntl.h
#include err.h
#include sys/types.h
#include sys/ata.h
int main(int argc, char **argv) {
struct ata_cmd iocmd;
struct ata_params ap;
int channel, device, fd, i;
if(argc != 3) {
errx(1, usage: %s channel device, argv[0]);
}
channel = atoi(argv[1]);
device = atoi(argv[2]);
if ((fd = open(/dev/ata, O_RDONLY)) == -1) {
err(1, error opening /dev/ata);
}
bzero(iocmd, sizeof(struct ata_cmd));
iocmd.channel = channel;
iocmd.device = channel;
iocmd.cmd = ATAGPARM;
if (ioctl(fd, IOCATA, iocmd) == -1) {
err(1, error executing ioctl);
}
if (iocmd.u.param.type[device]) {
ap = iocmd.u.param.params[device];
} else {
errx(1, no information for device %d channel %d,
device, channel);
}
printf(Model:);
for(i = 0; i 40 ap.model[i] != '\0'; i++)
printf(%c, ap.model[i]);
putchar('\n');
printf(Revision: );
for(i = 0; i 8 ap.revision[i] != '\0'; i++)
printf(%c, ap.revision[i]);
putchar('\n');
printf(Serial: );
for(i = 0; i 20 ap.serial[i] != '\0'; i++)
printf(%c, ap.serial[i]);
putchar('\n');
return 0;
}
Cheers,
Vik
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On Tue, 15 May 2007, Tom Evans wrote: On Tue, 2007-05-15 at 11:23 -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Dag-Erling Smørgrav [EMAIL PROTECTED] typed: Peter Jeremy [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: [Linux package systems] As far as I know, none of them handle updates from source at all. In fact, dealing with sources seems to be a noticable weakness for them. This pretty much rules them out then. It would, if it were true. It isn't. Except it is. apt-get --build source package_name That doesn't update from sources, that just builds a package. You're still stuck updating from packages. Further, like the rpm command, this doesn't deal with dependencies, other than to complain if they aren't met. This means that using it to deal with sources is about as pleasant as using rpm to install binary packages. Further, there doesn't appear to be anything like make.conf to make it easy to tailor the build process to meet the users requirements. mike Of course Gentoo does do this [updating from source], being as it is a rip-off of freebsd ports. I haven't used it since the (fairly) early days when portage was written as a series of bash scripts. I'm fairly sure they must have improved it since then - it made portupgrade look positively snappy. Unsurprisingly, everything was/is controlled by adding options (mainly USE_FLAGS - eg '+gtk2 -kde') to make.conf. Tom Tom, It's gotten excruciatingly more complex with the introduction of Python, classes, and an increase in USE flags. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
On 2007-05-14 13:19, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Dag-Erling Smrgrav [EMAIL PROTECTED] (from Mon, 14 May 2007 11:31:25 +0200): Note that we are apparently not the only ones dissatisfied with this state of affairs. The following code is commonly found in rpm specs for Fedora (and, I suspect, for RedHat and CentOS as well): sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool Perhaps we could make common cause with RH to apply pressure on the libtool maintainers? Quite good idea, if this means the fixes will automagically work for libtool for releases = 1.5.X. Things may be a little trickier with older libtool versions, but I'm not sureif I'm qualified to suggest a *real* fix for those thirdparty packages which depend on older libtool versions. Isn't this a property which can be set at build time? I mean: isn't there a $OSNAME case where this can be set for a specific OS? There is already precedent for OS-specific and compiler-specific options. The 1.5.23a version includes already special support for linking with -library=stlport4 and _excluding_ the -lCrun and -lCstd libraries for Solaris programs compiled with Sun Studio ;-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SoC
On Tuesday, 15 May 2007 at 1:05:07 -0700, Garrett Cooper wrote: Tom Evans wrote: On Mon, 2007-05-14 at 22:17 -0700, Garrett Cooper wrote: Ruby's nice, but it's built on Perl so I have suspicions on its overall usability / speed given my experience with Perl over the past 4 months daily for work :(.. Ruby's just the new big thing for programming languages, so everyone's into it. Kind of like how Java was compared to C/C++ a few years back. But once everything dies down people will realize that they'll still have to program in C/C++/Perl for real-world applications. Python seems better than Ruby from what I can see, but I really don't like the mandatory indentation thing. Ew.. Rubies are better Perls. That's the only connection between the two. One day, a Japanese programmer got fed up with Perl, and wrote a better language (for varying meanings of better). Its not based or built on Perl in any respect. Python and Ruby both have the same targets; to speed development time and increase programmer productivity. But one must make a Perl before one can make a Ruby. Maybe that was what I was trying to aim for. Ruby's nice, but it seems like it's going to be a bit passe in a few years like Java was for compilable / interpretable languages. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] None of this matters My only point is that if you need something quick to explore the format of pkgdb.db or INDEX.db you are pretty well assured of finding a tool you can work with; Perl, Python, or Ruby. If these aren't sufficient use C. The pkg_* tools are written in C so in C they will be modified; but no harm in doing initial exploration and prototyping with something else. Let's stay focused! Duane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experiences with 7.0-CURRENT and vmware.
On Thursday 10 May 2007 07:13:26 am Darren Reed wrote: I'm using FreeBSD 7.0-CURRENT under vmware and there are a few issues. First, time. hint.hw.acpi.disabled=1 This appears to make _no_ difference to time keeping on FreeBSD 7 and nor does it seem to have any impact on ACPI being loaded. Do I need to recompile a new kernel without it or is there a new way to disable ACPI? The tunable is 'hint.acpi.0.disabled=1' man 4 acpi Second, networking. Prior to FreeBSD-7, the driver to use inside vmware workstation was lnc. It has worked and contiues to work great. No problemo. FreeBSD-7 uses the em driver. To put it simply, it sucks in comparison. When things really get bad I start seeing em0: watchdog timeout messages on the console. I looked and I don't see a lnc driver anywhere. Is there another alternative (le?) driver that I can use in place of em, if so, how? le(4) is the newer lnc(4). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
