Re: Completely offtopic : [OT?] Coding Style
In message [EMAIL PROTECTED], Mike Harrold wrote: Then there is reasability. void ThisIsMyDumbassFunctionName if MUCH more difficult to read than void this_is_my_clear_and_easy_function_name This may hold for English (or native English speakers, respectively) but not for other languages (e.g. German) where capital letters quite common. [Fullquote deleted] Bernd -- Bernd Petrovitsch Email : [EMAIL PROTECTED] G.A.M.S GmbH Fax : +43 1 8958499-60 Stiegerg. 15-17/8 A-1150 Vienna/Austria/Europe LUGA : http://www.luga.at PGP signature
Re: About IP address
To throw additional information (or confusion or simply wrong stuff?) in :
In message [EMAIL PROTECTED], "Michael H. Warfield" w
rote:
I have been unable to find any documentation in the RFCs
which lay claim to restricting 128.0.*.* or 191.255.*.*. The fact
RFC1940, though it's "only" informational, bottom of page 7 :
--- snip ---
Source Route (variable)
The components of the source route are syntactically IP
addresses.
An IP address from network 128.0.0.0 is used to encode a next
hop that is a domain. The least significant two octets contain
the DI, which is an Internet Autonomous System number.
--- snip ---
Bernd
--
Bernd Petrovitsch Email : [EMAIL PROTECTED]
G.A.M.S GmbH Fax : +43 1 8958499-60
Stiegerg. 15-17/8 A-1150 Vienna/Austria/Europe
LUGA : http://www.luga.at
PGP signature
Re: Kernel compile trouble
# # # Gameport joysticks # # # Serial port support # # # Serial port joysticks # # # Parallel port joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set CONFIG_DRM=y CONFIG_DRM_TDFX=y # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_JFFS_FS_VERBOSE=0 CONFIG_CRAMFS=m CONFIG_RAMFS=m CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_MINIX_FS=m # CONFIG_NTFS_FS is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_ROMFS_FS=m CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # # Sound # CONFIG_SOUND=y # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set CONFIG_SOUND_ES1371=y # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set # CONFIG_SOUND_SGALAXY is not set # CONFIG_SOUND_ADLIB is not set # CONFIG_SOUND_ACI_MIXER is not set # CONFIG_SOUND_CS4232 is not set # CONFIG_SOUND_SSCAPE is not set # CONFIG_SOUND_GUS is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_VMIDI is not set # CONFIG_SOUND_TRIX is not set # CONFIG_SOUND_MSS is not set # CONFIG_SOUND_MPU401 is not set # CONFIG_SOUND_NM256 is not set # CONFIG_SOUND_MAD16 is not set # CONFIG_SOUND_PAS is not set # CONFIG_SOUND_PSS is not set CONFIG_SOUND_SB=m # CONFIG_SOUND_AWE32_SYNTH is not set # CONFIG_SOUND_WAVEFRONT is not set # CONFIG_SOUND_MAUI is not set # CONFIG_SOUND_YM3812 is not set # CONFIG_SOUND_OPL3SA1 is not set # CONFIG_SOUND_OPL3SA2 is not set # CONFIG_SOUND_YMPCI is not set # CONFIG_SOUND_UART6850 is not set # CONFIG_SOUND_AEDSP16 is not set # # USB support # # CONFIG_USB is not set # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y Bernd Petrovitsch Email : [EMAIL PROTECTED] G.A.M.S GmbH Fax : +43 1 8958499-60 Stiegerg. 15-17/8 A-1150 Vienna/Austria/Europe LUGA : http://www.luga.at PGP signature
Re: Style Question
On Sun, 2007-03-11 at 22:15 +0800, Cong WANG wrote: [...] Another question is about NULL. AFAIK, in user space, using NULL is better than directly using 0 in C. In kernel, I know it used its own NULL, which may be defined as ((void*)0), Userspace has the usually same definition. but it's _still_ different from raw zero. It is different that 0 as such has the type int. But this int is automatically promoted to a 0 pointer. So can I say using NULL is better than 0 in kernel? Yes, because it is immediately clear that a pointer is (or should be) there (and not an int). And the same holds for userspace since this is a pure C question. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h) (was: Re: [KJ] [RFC] A need for a yesno-function?)
On Fri, 2007-03-16 at 16:24 +0100, Richard Knutsson wrote: [...] more readable). The big problem is, where to put it? Seems wrong to put in linux/string.h since it appear to be a replica of userspace's string.h (otherwise, why put mem*-functions in there?). memcpy(3) and memcmp(3) are also there in user-space. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h)
On Fri, 2007-03-16 at 18:09 +0100, Richard Knutsson wrote: Bernd Petrovitsch wrote: On Fri, 2007-03-16 at 16:24 +0100, Richard Knutsson wrote: [...] more readable). The big problem is, where to put it? Seems wrong to put in linux/string.h since it appear to be a replica of userspace's string.h (otherwise, why put mem*-functions in there?). memcpy(3) and memcmp(3) are also there in user-space. Did I miss something or did you just restate what was stated? (If it was not a replica, I think the mem*-functions would be better placed in memory.h, or such) Ah, I misunderstood it as if you wonder why mem*() functions in string.h. Sorry. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style RFC: convert for (i=0;iARRAY_SIZE(array);i++) to array_for_each(index, array)
On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote: Joe Perches wrote: [...] perhaps: #define array_for_each(element, array) \ for ((element) = (array); \ (element) ((array) + ARRAY_SIZE((array))); \ (element)++) If you're going for consistency, then shouldn't this be array_for_each_entry()? That depends on the decision between consistency to array_for_each_index or consistency to list_for_each. #define array_for_each_index(index, array) \ for ((index) = 0; (index) ARRAY_SIZE((array)); (index)++) Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style RFC: convert for (i=0;iARRAY_SIZE(array);i++) to array_for_each(index, array)
On Tue, 2007-02-13 at 21:54 +1100, Nick Piggin wrote: Bernd Petrovitsch wrote: On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote: Joe Perches wrote: [...] perhaps: #define array_for_each(element, array) \ for ((element) = (array); \ (element) ((array) + ARRAY_SIZE((array))); \ (element)++) If you're going for consistency, then shouldn't this be array_for_each_entry()? That depends on the decision between consistency to array_for_each_index or consistency to list_for_each. I don't follow. Yes, thinko on my side. Sorry. list_for_each gives you a list_head. list_for_each_entry gives you a pointer to an entry in the list, which is equivalent to the above loop which gives a pointer to an entry in the array. Accordingly, it should be called array_for_each_entry. What sort of logic leads to another conclusion? The wrong logic that list_for_each gives an entry. Sorry f.t. confusion. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 22:27 -0800, v j wrote: [...] here. I am perfectly willing to live with the way Linux is today. I am telling you as a user that if Linux continues on the current path it will become less and less attractive to Embedded Users. Which is only (or more accurate: at most) true if the kernel module developers actually work for the company selling the product. And it is not (necessarily) true if the company selling the product hires external people or companies for such a job - than it is much better (and cheaper) if you get the whole source. It takes a lot of time (both work time and calendar time) to coordinate debugging of 2rd party closed source modules. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 23:28 -0800, v j wrote: On 2/14/07, Randy Dunlap [EMAIL PROTECTED] wrote: At least one of us is confused about that an embedded User is. It seems to me that you are an embedded developer, not User. I doubt that most Embedded Users care what their OS is, or even know what an OS is. I am not sure what the difference is. We are trying to use Linux to support our application. It may be that Linux has a bug, or our application. When it is Linux, that has the problem, I have tried to inform the community of that. It would be much more helpful - especially for your product - to fix the bug. And to stay open you can also submit the patch. Not everybody has to be a contributor. The reason Linux is popular is because of its openness. Take that away and see where it goes. We seem to have different definitions of open and closed. Open = 3rd party Linux drivers can be loaded. Closed = No third party Linux drivers can be loaded. You can always load 3rd party drivers - even if you compile module support out of it. Or do you really meant: Closed == No closed source 3rd party drivers will be loaded because it is the decision of the company that pays the developers. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wed, 2007-02-14 at 22:46 -0800, v j wrote: You don't get it do you. Our source code is meaningless to the Open Source community at large. It is only useful to our tiny set of Perhaps you should leave that decision to the open source community at large. [ Useless fullquote deleted ] Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 15:37 +0100, Benny Amorsen wrote: JDL == Jan De Luyck [EMAIL PROTECTED] writes: JDL I think a nice example of that might be the Linksys WRT54G JDL routers. They don't ship with Linux anymore, except the WRT54GL. Apparently switching was worth it to save 2MB flash. If you sell that many of them (several thousand per month?), it is it worth. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote: Ben Nizette wrote: [...] Question to the world here: Distros make, as a matter of course, a series of modifications to the Linux Kernel so that their modules or features work. What stops VJ making a patchset which effectively s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g 's the kernel source then distributing that under the GPL? He then supplies his un-GPL'd modules Nothing. But it is pointless since that doesn't un-GPL source code. [...] Rhetorical question: what stops me from taking somebody's copyrighted work, stripping the copyrights or falsely claiming to have a license to redistribute it, then selling it? No one. But that doesn't make the action legal or change the copyright/authors rights in anyway (at least in the more civilized parts of the world). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 17:41 -0500, Jeff Garzik wrote: Bernd Petrovitsch wrote: On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote: Rhetorical question: what stops me from taking somebody's copyrighted work, stripping the copyrights or falsely claiming to have a license to redistribute it, then selling it? No one. Well, that's not quite true, is it? This little microcosm of life has its checks and balances, and certainly strives for an equilibrium. You make a choice, as in Nick's example, to balance the risk of being ACK. caught, being sued, being shamed, and/or being avoided by customers against the perceived rewards. ACK, *iff* you get caught. But I cannot stop you if you just do it. Perhaps I can stop you later on if I find it out, can proove it sufficient to go to court (or at least threaten enough) and have the economical power to do it. Negative incentives are present, is the overall answer, even if they are not immediately obvious and spelled out in excruciating detail. Of course. And given the cases on gpl-violations.org I fear I'm right. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Fri, 2007-02-16 at 03:19 -0500, [EMAIL PROTECTED] wrote: [...] Actually, the *real* reason embedded systems end up using old versions is much simpler. ACK. They start developing their code on release 2.X.Y, and they keep their code out-of-tree. Then, when they come up for air, and it's at 2.X.(Y+15), they discover that we weren't kidding when we shipped stable_api_nonsense.txt, and since their code isn't in the tree, they have to do all the API cleanup themselves, because no flock of nit-picking kernel janitor monkeys swarmed over their code and magically fixed it up for them. Actually it is questionable for product development in a commercial environment (especially in the embedded world where you usually have a quite defined hardware and software on your device) if one actually wants that - think of the if it's not broken, don't fix it reason. And unless Y+15 has some *very* compelling reasons to move forward, just sticking at Y suddenly starts looking very good, because watching somebody else's kernel janitor monkeys fix your code is fairly cheap, but paying your own kernel janitor monkeys gets expensive really fast It depends on the *very* compelling reason if it is easier/cheaper to a) fix the problem in the old kernel, b) backport something or c) forward port the own drivers/changes. And that decision depends on lots of factors (and company-internal bureaucracy with the QA department may not be the least important). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote: [...] Note that it is possible that what vj said is strictly true. IF the product they ship is non-modifiable, then it's hard to argue that anyone else could maintain it. And if the drivers are for devices The GPL has no special handling for that case. proprietary to their hardware, then they have no real value to anyone else. And the drivers MIGHT contain information useful to their actual competitors. I have no knowledge as to whether those conditions And that may a (BTW invalid) reason for lots of companies but you probably won't find an exception in the GPLv2 for this. And if you infringe on others' patents, you should probably look elsewhere for a solution of that problem. actually apply. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 22:25 -0800, v j wrote: [...] No, just that the trend is disturbing. If enough Kernel Developers choose to write their Software in a way that prevents others from using it freely, then that is troubling. Especially when these Kernel You can use it freely - your definitions of free and closed are broken (at least on LKML). Developers are substituting existing interfaces in the Kernel with ones that are NEW and require specific licenses. That claimed specific license is the very same license that the rest of the kernel has since day 1. So what? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kernel porting query
On Fri, 2007-02-16 at 07:46 +0530, Rick Brown wrote: Your quoting style sucks. I fixed it by hand. [...] 1) Can any one please shed some light on precisely and exactly what are differences in different boards for which we need to port linux? On Fri, 2007-02-16 at 09:48 +0530, Ajay Singh (ajaysi) wrote: The differences depends on the boards ... Mostly if they belong to the same family the differences could be mainly in the peripherials ... Interrupt mappings... Serial interface ... Memory sizes (if differnet boards have different memory sizes) ... Sometimes some devices may be moved to some other locations in the memory map (Look at memory map of your SoC on your board). You may have different boot loaders (or none at all). You also may have different storage media like FlashRAM, IDE, network, for boot loader/kernel/root filesystem. They may have different sizes and it makes a little difference for your requirements in the toolchain if you have 4MB or 1GB to boot your system from. All that kind of information can be found in a BSP (board support package). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL vs non-GPL device drivers
On Fri, 2007-02-16 at 03:42 -0800, David Schwartz wrote: [...] Not quite. Copyright is: This particular implementation is mine, but you are free to implement any idea any *other* way you want. You simply can't implement an idea precisely the way I did it, but all ideas are open to you. Actually you can legally (at least/even with author's rights hereover). But it will be very hard to convince a judge and/or lawyers that you didn't actually copy it. And the question is moot anyways since it is extremely unlikely you end up with the same implementation for the same problem (unless the problem is small/simple/trivial enough like binary search in a sorted array on int's). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Mon, 2007-02-19 at 21:19 -0800, v j wrote: [...] Now it would also be worthwhile to contemplate what EXPORT_SYMBOL_GPL does to this popularity. I don't know. I am just giving you my The big problem with such discussions (as this) are: It is a law decision which license applies in which situation. And preprocessor can solve this (so EXPORT_SYMBOL_GPL may mean that or may only express the wish of one/several/many/a lot of people). Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the users view if the GPL spreads over or not (and the usual technical terms like linking are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must fit wit the library license. Guess now what this implies for (typical) embedded systems with one piece of GPL code in it where you download complete firmware images - and he explicitly confirmed that. So this whole thing is not really defined yet and one (read: we) must also educate such free-software-illiterate people on how it is intended to work. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Tue, 2007-02-20 at 10:14 -0500, [EMAIL PROTECTED] wrote: On Tue, 20 Feb 2007 12:00:51 +0100, Bernd Petrovitsch said: Flame bait alert: I heard a talk from an Austrian lawyer an according to his believes (and I don't know if he is the only one or if there lots of) one must see from the users view if the GPL spreads over or not (and the usual technical terms like linking are basically irrelevant). E.g.: - You are distributing an application which links against a GPL-library. If you provide a link and the user/customer has to get and install that library, your application can have any license you wish. - If you distribute an application and it installs automatically a library (e.g. from the CD where your application is installed), your applications license must fit wit the library license. So tell me - if RedHat distributes a non-GPL program that uses a GPL library that is included as part of the distribution, but *not* one that's usually installed, which rules apply? I'm well aware that there are (probably lots of) contradictions with this idea. IANAL and we must ask that lawyer actually for this. And he will probasbly do not understand the question since he very probably doesn't know all the usual software distribution methods. Even better - does this mean that I can *intentionally* bypass the licensing by including a installer script that removed a problematic library, and then forces the user to re-install it? A good question which belongs in the same category as above. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
Sorry for feeding the troll: On Die, 2008-01-08 at 17:52 +, Tuomo Valkonen wrote: On 2008-01-08, Andre Noll [EMAIL PROTECTED] wrote: Use tune2fs to deactivate checking. So, a workaround is the answer to a clear bug. Typical FOSS. At least you get a simple solution for your problem: Configure your system in a slightly different way (once!) and that's it. There are far too many commercial vendors out there where you probably wouldn't get an answer at all. And if, days or weeks later. And if a - in your opinion! - wrong default value (for whatever reason) is a bug in your universe, then you should probably adopt the interpretation of words of this universe. BTW changing the default value in the source now doesn't fix the sub-optimal default value on your system. Modify the init scripts or use another distro. Another typical FOSS answer. You have the source, you can fix it. With what time? If you don't have the time to fix your problems, why should anyone else have the time to fix your problems? That is BTW the typical i'm your customer and you have to obey me attitude. Perhaps you want to buy somewhere the time to fix your problems. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch.pl: allow piping
On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote: On 01/11/2008 10:17 AM, Daniel Walker wrote: On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote: On 01/11/2008 05:10 AM, Daniel Walker wrote: A little feature addition to allow checkpatch.pl to check patches piped into it, in addition to specific file arguments. You can still add - as an argument to check stdin. In which way is this better? There's was no reason to limit the arguments .. I was using it to do something like the following , git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl Ok, and if you add a - there, it should have the same effect, but for free, doesn't it: git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl - JftSoC: git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl /dev/stdin (and there a a few others) should also do the trick. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch.pl: allow piping
On Fre, 2008-01-11 at 01:47 -0800, Daniel Walker wrote: On Fri, 2008-01-11 at 10:41 +0100, Jiri Slaby wrote: On 01/11/2008 10:36 AM, Daniel Walker wrote: On Fri, 2008-01-11 at 10:34 +0100, Jiri Slaby wrote: If somebody is hacking kernel, I think he should know the - trick used in many programs, but do not consider this as a nack. I'm hacking the kernel, and I didn't know the - trick .. So you have your testing case all in one with the patch submitter .. OK, maybe we should base it in doc for patch submitting then? It's in the bash docs I'm sure, it's just a matter of who ends up Yes, too. And awk also supports that. But /dev/stdin is also since ages a symlink to /proc/self/fd/0 (which is another equivalent file). reading that part of the docs.. I still think my patch is a good one , we could change the name to Allow piping with out tricks I suppose .. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch.pl: allow piping
On Fre, 2008-01-11 at 01:30 -0800, Daniel Walker wrote: On Fri, 2008-01-11 at 10:23 +0100, Bernd Petrovitsch wrote: On Fre, 2008-01-11 at 10:21 +0100, Jiri Slaby wrote: On 01/11/2008 10:17 AM, Daniel Walker wrote: On Fri, 2008-01-11 at 09:52 +0100, Jiri Slaby wrote: On 01/11/2008 05:10 AM, Daniel Walker wrote: [...] I was using it to do something like the following , git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl Ok, and if you add a - there, it should have the same effect, but for free, doesn't it: git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl - JftSoC: git show 9914cad54c79d0b89b1f066c0894f00e1344131c | ./scripts/checkpatch.pl /dev/stdin (and there a a few others) should also do the trick. Not a particularly attractive command line .. Might still be a good idea Might be. But it works for (almost?) all programs (which do not need seekable input) which absolutely want the input file specified by a parameter. And if it's an proprietary program, you can't even patch it. to add this since these two forms alluded me, and are likely to allude people new to unix all together (who is more likely to be using this particular tool).. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote: [...] ntpdate isn't run by any of the init scripts. ntpd is, but like I Yes, that is a usual bug/problem in common distributions[0] as there is no real guarantee that your clock is not far off. Add your timeservers in /etc/ntp/step-tickers whereever your distribution looks into to decide if ntpdate should run or activate the ntpdate init.d script. And some distributions run `ntpdate` quite late BTW already mentioned, I doubt it would correct vastly incorrect time, not even being able to track and correct when it advances fast. That the reason to activate `ntpdate` unconditionally: It sets the current time to an (somewhat) accurate value and `ntpd` handles the rest. Bernd [0]: Perhaps there is some reason for this. However I don't of any and none came ever to my mind. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote: Yes, that is a usual bug/problem in common distributions[0] as there is no real guarantee that your clock is not far off. It isn't, right after boot. But while the system is on, it sometimes starts advancing very fast, 15min a day or so. To my knowledge, the time the CMOS clock is not used then, but rather the kernel tracks the ACK. time based on scheduler interrupts, with ntpd occasionally correcting. However, ntpd refuses to correct when the time has drifted too much, causing even further drift. That shouldn't happen. That the reason to activate `ntpdate` unconditionally: It sets the current time to an (somewhat) accurate value and `ntpd` handles the rest. Nope, as explained above. ntpdate at boot wouldn't help much, because the time is (approximately) correct after boot. It only drifts after it. Aha. That's also strange. `ntpd` is able to (and always does AFAIK) modify the speed of the clock (to keep it synchronized) so that the error is usually much smaller than 1 second - also if you are behind high-jitter links and/or an a high stratum. That leads to the question why the clock starts to run like crazy at some time so that `ntpd` can't cope with it. Playing with `ntpd` parameters (e.g. increasing ) doesn't help I assume. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote: On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote: That leads to the question why the clock starts to run like crazy at some time so that `ntpd` can't cope with it. I do wonder whether the PSU could've been causing it. Now that think We have some embedded systems where some strange problems[0] were caused by bad/cheap/low-quality PSUs. about it, I got the PSU around two years ago, just like I compiled 2.6.14. This PSU coincidentally seems to have been the cause of the crash that started this thread, and went completely silent during the same day, on the third crash. But even if the PSU could cause the timer interrupt to signal too frequently or so, doesn't explain why nearly always after a crash (when journal recovery would be the normal course of action), fsck starts checking with absurd intervals since last check, whereas there's no trouble booting after normal shutdown. But for normal PCs, I don't know how much the quality of a PSU is relevant for the speed of the clock. Can you test with a different PSU? Bernd [0]: I don't know more details out of the top of my head. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building a kernel-source RPM (not a kernel RPM)?
On Wed, 2007-09-12 at 09:13 -0700, Dan Stromberg wrote: I sent this to kernel newbies first, and while I got one response there, it answered a different question than the one I was asking... Are you sure? I'm on a SuSE system. I'm working on automating the install of said system, but it needs a Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so that we can build modules in the field as needed. Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses for nameing convention and reverse engineer the .spec file. Fedora BTW abandoned kernel-source* and they have now a website with a description how to produce a configured kernel source tree (e.g. for out-of-tree modules). I see you can make an rpm of a bootable kernel with make rpm. Well, then there must be a .spec file somewhere which just wants to be extended. Is there a streamlined way of building a corresponding kernel-source RPM? Or do people pretty much all just dump the source in /usr/src, and Yes, you put all the steps you do by hand into the .spec file. That's it. manually update symlinks as needed? If the latter, what symlinks need to be updated? Actually nowadays usually there no sym-link updating anymore necessary - just put the correct ones in /lib/modules/$(uname -r)/ and the full name in /boot/grub/menu.lst. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building a kernel-source RPM (not a kernel RPM)?
On Wed, 2007-09-12 at 19:05 +0200, Sam Ravnborg wrote: [] Being rpm ignorant I do not know what the expected content of a kernel-source RPM are but this is the available targets for kernel packaging (from make help): The kernel-source including all patches and configured as usually to be found under /usr/src/linux-$VERSION (or so). One needs that for e.g. external modules. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building a kernel-source RPM (not a kernel RPM)?
On Wed, 2007-09-12 at 10:31 -0700, Dan Stromberg wrote: On Wed, 12 Sep 2007 19:09:26 +0200, Bernd Petrovitsch wrote: [...] I'm on a SuSE system. I'm working on automating the install of said system, but it needs a Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so that we can build modules in the field as needed. Find a kernel-source.*.src.rpm or kernel-*.src.rpm or whatever SuSE uses for nameing convention and reverse engineer the .spec file. Fedora BTW abandoned kernel-source* and they have now a website with a description how to produce a configured kernel source tree (e.g. for out-of-tree modules). So this is as smooth as producing kernel-source RPM's gets? I had no problems with the kernel-source.*.rpm approach. I might be better off sticking with a .tar.bz2 and repointing symlinks. I see you can make an rpm of a bootable kernel with make rpm. Well, then there must be a .spec file somewhere which just wants to be extended. I'm not sure this is going to be any easier to automate, if that's what's required. The problem, that automation of such a task depend on various factors (which may be somewhat private): - you have a linux-$VERSION:tar.bz2 - optionally, you have patches. And some distributions have *lots* of. - you need a .config (and run `make oldconfig`). You have to decide on each (independent if you build an RPM or a script) of them. If you need regularly .rpm from ongoing development, you probably need to figure out first which procedure is the best. It's from a conceptual view different if you either have your kernel source and produce new kernels every other day for testing, etc. (then simple scripts are more than enough) or you produce a .rpm every other day to install it and keep it for months (for whatever reason). [...] I may just stick them in a bash script and forget about the RPM. Or are A .spec file is a just set of scripts, some meta-information and produces a container. And you have a package management at install time. I can't decide if the more effort for the .rpm pays off for you - that also depends on factors like geek value, number of installations, And that the reason for me to suggest to find a recent SuSEs kernel.src.rpm and start from there or find the one behind the make rpm thingy. [] On OpenSuSE 10.2, there appears to be: # find / /home -xdev -ls | egrep -- '- /usr/src/linux' 2156410 lrwxrwxrwx 1 root root 26 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/source - /usr/src/linux-2.6.18.2-34 2137860 lrwxrwxrwx 1 root root 45 Sep 11 17:50 /lib/modules/2.6.18.2-34-default/build - /usr/src/linux-2.6.18.2-34-obj/x86_64/default Yup, but these (usually) don't change at run-time. So I would put them into the .rpm like any other sym-link (or delete and create them in the pre-rm and post-install scripts if it's not fixed at rpm-build-time). just put the correct ones in /lib/modules/$(uname -r)/ and the full name in /boot/grub/menu.lst. Which correct ones? Sometimes pronouns aren't shortcuts :) Sorry, the correct sym-links. Since I have no experience with recent SuSE, I didn't know that's the same as in the RedHat world (but they point somewhere else). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building a kernel-source RPM (not a kernel RPM)?
On Wed, 2007-09-12 at 19:51 +0200, Sam Ravnborg wrote: On Wed, Sep 12, 2007 at 07:11:21PM +0200, Bernd Petrovitsch wrote: On Wed, 2007-09-12 at 19:05 +0200, Sam Ravnborg wrote: [] Being rpm ignorant I do not know what the expected content of a kernel-source RPM are but this is the available targets for kernel packaging (from make help): The kernel-source including all patches and configured as usually to be found under /usr/src/linux-$VERSION (or so). One needs that for e.g. external modules. For external modules you need a fully build kernel which may be clean up by make clean. Thats not the same as a source RPM as per my understanding. Yes, if source RPM means files named like kernel-$VERSION.src.rpm. But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's which contain the kernel sources (read: lots of .c and .h files, etc.) - including a matching .config and after `make oldconfig` - so that one can build out-of-tree modules after installing it with KSRC= (or whatever the Makefile parameter is usually called). And such kernel-source-$VERSION.$ARCH.rpm's may/will/should fall also out of a rebuild of a kernel-$VERSION.src.rpm. Bernd [0]: And Dan pointed it out explicitly right at the start BTW. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Building a kernel-source RPM (not a kernel RPM)?
On Wed, 2007-09-12 at 20:16 +0200, Sam Ravnborg wrote: But we are talking[0] about a kernel-source-$VERSION.$ARCH.rpm's which contain the kernel sources (read: lots of .c and .h files, etc.) - including a matching .config and after `make oldconfig` - so that one can build out-of-tree modules after installing it with KSRC= (or whatever the Makefile parameter is usually called). You need certain things of the kernel built before you can build external modules (if they use a sane build approach). Just including the .config with the kernel source is far from enough. ACK. That all must be done/prepared correctly for the kernel-source-*.rpm. And nobody said it is trivial or easy. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 9p: rename uid and gid parameters
On Thu, 2007-09-13 at 08:51 -0600, Latchesar Ionkov wrote: Zero was the value that was used before, even though it wasn't defined explicitly. I just defined a macro so we can see and eventually change it to something better. I don't know if there is a good default value. Is nfsnobody the same on all Linux distributions? Not necessarily. [] On 9/13/07, Eric Van Hensbergen [EMAIL PROTECTED] wrote: On 9/12/07, Latchesar Ionkov [EMAIL PROTECTED] wrote: Change the names of 'uid' and 'gid' parameters to the more appropriate 'dfltuid' and 'dfltgid'. ... strcpy(v9ses-name, V9FS_DEFUSER); strcpy(v9ses-remotename, V9FS_DEFANAME); + v9ses-dfltuid = V9FS_DEFUID; + v9ses-dfltgid = V9FS_DEFGID; ... +#define V9FS_DEFUID(0) +#define V9FS_DEFGID(0) I'm not sure if there is a good solution here, but I'm uncomfortable with using uid=0 as the default. I'm not sure if there is a default uid for nobody, but anything is probably better than 0. Looks like nfsnobody is 65534, we could use that - even if only as a marker for On 32bit hardware. On 64bit it is (similar to 32bit): (unsigned int)-2. the server to map it to nobody on the target system? What do you think? Particularly with attach-per-user, we probably need to look at interacting with idmapd or create our own variant real soon. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel source code repository?
On Don, 2007-12-06 at 21:46 +0530, Amogh Hushdar wrote: [...] none of this is available, at least a tarball that I can download using my browser? Look at http://www.kernel.org/ Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A peek at the future of storage
On Mit, 2007-12-12 at 10:02 -0800, Daniel Phillips wrote: On Wednesday 12 December 2007 09:46, J. Bruce Fields wrote: [...] People have proposed writing a daemon that just reads /proc/net/rpc/nfsd periodically and uses that to adjust the number of threads from userspace, probably subject to some limits in a config file someplace. (Think that could do the job, or is there some reason [...] So how would a userspace daemon know that kernel is blocking and new threads are needed? In kernel this is pretty easy: when a new request arrives, look on the thread list and if none are available, generate a new one. Something special needs to be done to handle the case where there are no threads available because they are all piled up on a semaphore due to, for example, somebody unplugging the network cable for a remote disk. We have to avoid generating infinite threads in that case. Ideas? Add a sysctl configurable maximum number of NFS threads and default it to 8 (or whatever now the default value is). And one wants probably some logic to kill them again if they are not used long enough. And then you need/want another variable for the minimum number of NFS threads around. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Get physical MAC address
On Mon, 2007-12-31 at 12:39 +0700, Theewara Vorakosit wrote: [...] I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? - You can get the initial MAC address right after bootup before anyone changes it. - Some (if not many if not all) of the drivers output it on driver initialization time so you could read it from `dmesg` or some /var/log/messages or . There is no get initial MAC address ioctl (but it's not that complicated to implement it). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Get physical MAC address
On Die, 2008-01-01 at 22:58 -0600, Matt Domsch wrote: On Mon, Dec 31, 2007 at 12:39:11PM +0700, Theewara Vorakosit wrote: Hello, I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? yes. It's ETHTOOL_GPERMADDR to the ethtool ioctl. case ETHTOOL_GPERMADDR: rc = ethtool_get_perm_addr(dev, useraddr); break; When the driver is first loaded, before ifconfig can change the MAC address, the existing (permanent) MAC address is stored away, able to be retrieved via this ioctl. Jon Wetzel, a Dell intern of a few summers ago, wrote the code and was able to have it included. I stand corrected. Last time I looked for such a thing it didn't exist. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote: [] Key-based masterlocks are easily broken with freon, and their combo locks are easily brute-forced in about ten minutes. Yet, I'll still use them to lock up my bike and garage. The question is what the security threat is and the value of the secured items. The idea that poor security is worse than no security is fallacious, and not backed up by common experience. The common experience is, that common people just *feel* safer (just because they have poor security). With no security, they know that there is no security. With poor security, they do not know (or can deny) that they have next to no real security. The prime example here is the usual (so-called) personal firewall on Windows where people work normally as administrator. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
On Thu, 2007-10-25 at 09:04 -0700, Ray Lee wrote: On 10/25/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote: On Mit, 2007-10-24 at 17:35 -0700, Ray Lee wrote: [] Key-based masterlocks are easily broken with freon, and their combo locks are easily brute-forced in about ten minutes. Yet, I'll still use them to lock up my bike and garage. The question is what the security threat is and the value of the secured items. The idea that poor security is worse than no security is fallacious, and not backed up by common experience. The common experience is, that common people just *feel* safer (just because they have poor security). Do you lock your bike up when you leave it lying around? My point is that real security comes in layers, not one perfect solution that will always work everywhere for everyone. The latter is a pipe-dream. Of course not. Security as such is more than less only risk management (or part of it - depending of the viewpoint). With no security, they know that there is no security. With poor security, they do not know (or can deny) that they have next to no real security. The fallacy here is to believe that just because they have no security, that it will *in*any*way* change their behavior. I deal with real users daily, and *they*don't*care*. Further, there's no level of If people don't care, they are pretty lost anyway. That's actually the reason for all that security stuff that no one wants but which stands in the way of all people just because of the don't care faction (which by far the majority of all in any given area). But there is that (also not too small) I installed $PERSONAL_FIREWALL and *nothing* can happen because $VENDOR and $TECH_JOURNALIST in $LOW_QUALITY_PC_MAG said so faction. education that we can instill into the community to make them aware of the issues and change their habits accordingly, because real users don't have the background to understand those lessons. While you can teach them that running an executable from someone they haven't heard of is obviously bad, they don't know why downloading an image is potentially dangerous, it's an image, right? Well, there's these things called buffer overflows... eyes glaze over Security is not an all or nothing game, it's layers. And we have to And every layer/subsystem/area must be checked and seen independently of others (or the dependency must be that strong that no one can work around). And every security layer will and should have it's purpose and targets. make sure that the layers are usable without taking a course from the NSA. I'd love to see a poll of the kernel development community to find out how many use SELinux on their machines, for example. selinux=0 on the kernel commandline is normal - no unknown people have logins and so there was no reason to learn it. And against should it protect in the first place if only trusted people are there? The prime example here is the usual (so-called) personal firewall on Windows where people work normally as administrator. So your argument is that if there weren't a personal firewall on Windows, that a significant number of people would then not run as Administrator? I beg to differ. No, how do you come to that conclusion? People login as Administrator because they did it since DOS3.0. People buy and install $PERSONAL_FIREWALL because some cheap PC tech magazine had advertisements for them. Next generation (or this generation?) viruses/malware will either reconfigure $PERSONAL_FIREWALL silently (and if course only temporarily). And the vendor of $PERSONAL_FIREWALL writes into the manual (which no one reads) or the EULA (which no one reads because it isn't relevant in the first place) or some README (which no one finds) that one must not login as Administrator. But that just to keep the vict^Wbuyers to not sue them. And working on Win* without being Administrator is a real PITA - so the average user won't do it for long. So apart from the personal feelings of that user I can't find any sign of security. BTW from a commercial viewpoint, the (so-called) personal firewalls were probably one of the best ideas (and another major example that technical expertise has nothing to do with sales success). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Intel Manageability Engine Interface driver
On Die, 2007-10-23 at 15:35 -0400, Lennart Sorensen wrote: On Tue, Oct 23, 2007 at 11:22:50AM -0700, Roland Dreier wrote: It's not a hard experiment to do. The answer is: warning: suggest parentheses around assignment used as truth value A warning is not an error. It won't abort the compile. Add -Werror. The warning (which I don't remember gcc doing in the past) is a nice idea though. That's the case since many years - I don't remember how long. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LINUX-KERNEL] C++ in linux kernel
On Mon, 2008-02-11 at 17:07 +0530, rohit h wrote: On Feb 8, 2008 9:24 PM, Jan Engelhardt [EMAIL PROTECTED] wrote: [...] Compiling the kernel module with g++ is not a simple work, you may need big patch for kernel itself. I don't want to compile entire kernel. I only want to compile my module with g++ and insmod it. Any hint on how to write the Makefile. You really should learn on the differences at run-time between between - pure C in a hosted environment (read: you have a full libc), - pure C in a standalone environment (read: e.g. the Linux kernel), and - C++ in both variants. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] Linux-tiny project revival
On Fre, 2007-09-28 at 00:21 +0200, Arnd Bergmann wrote: On Thursday 27 September 2007, you wrote: Then you don't have to change every single printk in the kernel, but only those that don't currently come with a log level. More importantly, you can do the conversion without a flag day, by spreading (an empty) PRINTK_CONTINUED in places that do need a printk without a log level. The problem is, how do you know whether to print a continued printk or not? It depends on the loglevel of the first printk. Those need to be looked at individually. You can normally see easily from If think you misunderstood: Say, you compile out everything of DEBUG level. Say, you have a continued printk() after each and every pr_debug(). Then how is the macro supposed to know (at compile-time) that the continued printk() actually belongs to a DEBUG printk (and not another one)? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Floating Point Issue
On Don, 2007-09-27 at 12:41 +0100, mahamuni ashish wrote: I have small code And the relevance to the Linux kernel as such is? [] Add -Wall -Wextra and fix all errors and warnings. Expected output is No. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for WindowsMobile5 on Linux Kernel
On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
[...]
Would it be possible to include the patches (available on www.synce.org)
for WindowsMobile5, as most mobile phones are under Window$, and it is
very convenient to connect it to the laptop under Linux
do {
Test them
review them
sent them as patches hereover
handle feedback
until(accepted)
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Sun, 2007-09-02 at 16:03 +0200, Marc Espie wrote: [...] So, now, it's down to dirty fighting. Absorbing and `relicensing' and evolving code. Have you all been bitten my RMS paranoia (that leads to this `interesting GPLv3) ? Do you intend to keep grabbing BSD code and putting it exclusively under the GPL ? AFAIK: I could take BSD- (or ISC-)licensed code (legally), patch it, sell it (nor not) and (legally) not give back anything putting the whole code effectively under proprietary license. And you can't do anything (except negative propaganda) independent if you are maintainer, author or whoever. And you seriously have a problem with GPLed patches (which is BTW more open since you cannot legally hide the changes once you gave a binary away - at least from the receiver of said binaries)? BTW it's the same as with other open code: Take it or leave it - it's your decision. SCNR, Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to learn Linux Kernel Programming
On Wed, 2007-08-22 at 06:47 +, Noud Aldenhoven wrote: Thank you for your information and help, I think it's a lot more clear for me now. I've seen the ldd3 some time ago, but someone told me that book was out-of-date. Guess he was wrong. Would it also be use full to use some kind of cross-compiler? (don't know if that's the right word for it) No. So I can run my stable kernel and on top of it a new experimental kernel where I can experiment with? Then you want to use UserModeLinux. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to register block device as read-only
On Fri, 2007-07-27 at 13:07 -0500, [EMAIL PROTECTED] wrote: Hello, In a block device driver, how do you tell the kernel that your block device is read-only? Is it in the registration of the gendisk, or is there an ioctl I should be catching to inform the kernel (and user) that this disk is read-only? Unless I misunderstand the question, the write and writev function of the struct file_operations should return an appropriate error value (which is here -EACCES). You may think of returning an error in the open if someone wants to open it to write to it (so that the must open it read-only). But I don't know if that is common practice or not (or even disliked) as it may interfere with not properly implemented tools which open devices read-write even if they never write to it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] type safe allocator
On Thu, 2007-08-02 at 15:47 +0200, Peter Zijlstra wrote: On Thu, 2007-08-02 at 16:04 +0400, Alexey Dobriyan wrote: On 8/2/07, Miklos Szeredi [EMAIL PROTECTED] wrote: The linux kernel doesn't have a type safe object allocator a-la new() in C++ or g_new() in glib. Introduce two helpers for this purpose: alloc_struct(type, gfp_flags); zalloc_struct(type, gfp_flags); ick. These macros take a type name (usually a 'struct foo') as first argument So one has to type struct twice. thrice in some cases like alloc_struct(struct task_struct, GFP_KERNEL) Save the explicit struct and put it into the macro (and force people to not use typedefs). #define alloc_struct(type, flags) ((type *)kmalloc(sizeof(struct type), (flags))) Obious drawback: We may need alloc_union(). SCNR ... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gcc fixed size char array initialization bug - known?
On Fri, 2007-08-03 at 11:40 +0800, WANG Cong wrote:
On Fri, Aug 03, 2007 at 08:47:56AM +0530, Satyam Sharma wrote:
[]
While we're talking of null-termination of strings, then I bet you
generally want to be using strlcpy(), really. Often strncpy() isn't
what you want. Of course, if that buffer isn't a string at all, then
you should be using memfoo() functions and not strbar() ones in the
first place ...
Afaik, strlcpy() and strlcat() are NOT standard C library functions.
Yes, because they are not old enough as they are results of lessons
learned with strncpy() and strcpy() and other buffer overflows.
But, I know, they are available in Linux kernel. ;) And yes, they
are better than strn{cpy,cat}().
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 2005-04-08 at 09:08 -0300, Humberto Massa wrote: Adrian Bunk wrote: Debian doesn't seem to care much about the possible legal problems of patents. You have lots of possible legal problems of any kind. Basically everyone can sue you for (almost) whatever he wants almost all ofth time. The possible legal problem of software patents is, up to the present time, AFAICT, not producing effects yet in Europe, and is a non-problem It is starting now. Basically the corporations with the masses of software patents and patent lawyers are probably waiting for the settling of the discussion and the ratification of the relevant to-be-accepted laws. And the war is not over yet ... In fact software patents are real in EUrope and they exist (though illegally). Up to now it was a question of whether you can succeed in court with them and which courts to go in jurisdictions like mine (down here neither business methods nor software are patentable). I suspect that .br is commercially not relevant enough for this ATM. Or the legislation is already USPTO-conform in place and nobody knows . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violation by CorAccess?
On Tue, 2005-04-19 at 17:37 -0600, Chris Friesen wrote: Richard B. Johnson wrote: No. Accompany it with a written offer to __provide__ the source code for any GPL stuff they used (like the kernel or drivers). Anything at the application-level is NOT covered by the GPL. That depends on the software used there. They do not have to give away their trade-secrets. Unless they coded them into GPL software ... GPL'd applications would still be covered by the GPL, no? Good question: Strictly speaking if you omit the GPL in the delivered ssoftware/product/whatever, you violated the GPL yourself and - thus - loose all rights which are given to you through the GPL. If I buy their product, I should be able to ask them for the source to all GPL'd entities that are present in the system, including the kernel, drivers, and all GPL'd userspace apps. ACK. Any *new* apps that they wrote they would of course be free to keep private. As long as they do not statically link against LGPL (or GPL) code and as long as they do not link dynamically agaist GPL code. And there are probably more rules . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process
On Tue, 2005-02-15 at 09:34 +0100, Paolo Ciarrocchi wrote: [...] So... why is Gentoo the only distro the uses parallel execution of init scripts ? Because no other distro bothered to implement it. Apart from that we as quite far off-topic for LKML since this has nothing to do with kernel. The only reason getting this on-topic is to try to get the best SWSUSP support in the kernel so one simply does not need this. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
On Tue, 2005-02-15 at 09:55 +0100, Helge Hafting wrote: [...] The init-script dependencies are specifies already - at least on debian. These are not dependencies but only the sequence of startup (and it is not only Debian but also Fedora/RedHat, SuSE, Mandrake and probably all except Gentoo). Yuo get a much stricter ordering and sorting (and thus much simpler to implement in a shell script). Look at the most used runlevel, ls /etc/rc2.d: S10sysklogd@ S11klogd S14ppp S18portmap S19slapd S20alsa S20cupsys S20dhcp3-server S20exim ... The numbers specify ordering constraint, low numbers must start before high numbers. But plenty of scripts have no interdependencies, I have 18 scripts numbered S20. This would be a win (especially if the numbers are tweked to tune this) with a relatively small effort. However for real dependencies and parallelism you want the info similar to creat a Makefile from it (i.e. the explicit dependency from service X to service Y). As a consequence you can get rid of the numbers (since they are not needed any more). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
On Tue, 2005-02-15 at 14:20 +0100, Helge Hafting wrote: Bernd Petrovitsch wrote: On Tue, 2005-02-15 at 09:55 +0100, Helge Hafting wrote: [...] These are not dependencies but only the sequence of startup (and it is not only Debian but also Fedora/RedHat, SuSE, Mandrake and probably all except Gentoo). Yes, it is a sequence. It it derived from real dependencies though, where nondependent stuff have the same number. Yes, of course. Sorry if that wasn't clear. However for real dependencies and parallelism you want the info similar to creat a Makefile from it (i.e. the explicit dependency from service X to service Y). As a consequence you can get rid of the numbers (since they are not needed any more). Now that is a really good idea. Init could simply run make -j init2 to Actually I just used it to illustrate the idea. As with Gentoo, I'm not a guru there so other people must comment if Gentoo actually starts services in parallel. enter runlevel 2. A suitable makefile would list all dependencies, and of course the targets needed for init2, init3 and so on. It might not be that much work either. Parallel make exists already, and the first attempt at a makefile could simply implement the current sequence that is known to work. Then the tweaking comes. :-) You just have to cope with the potentially parallel output reliably especially in error cases (which is IMHO basically the most work). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in SLES8 kernel 2.4.x freezing HP DL740/760
On Wed, 2005-02-16 at 22:03 +0100, Oliver Antwerpen wrote: Matthias-Christian Ott schrieb: Oliver Antwerpen wrote: SuSE has patched UNICON into the kernel which will cause these servers to hang when booted with vga=normal. The system will run fine in fb-mode, but not in plain text. Well if you don't need unicon, then remove the patch from the .spec file and rebuild the kernel (from the source rpm). Or report it their bug tracking system. My problem ist, that when I change .config, then I lose my support. So SuSE or HP have to tell me to do so. And they listen here to you? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v850: const-qualify first parameter of find_next_zero_bit
On Wed, 2005-07-20 at 17:38 +0900, Miles Bader wrote:
[...]
@@ -157,7 +157,7 @@
#define find_first_zero_bit(addr, size) \
find_next_zero_bit ((addr), (size), 0)
-extern __inline__ int find_next_zero_bit (void *addr, int size, int offset)
+extern __inline__ int find_next_zero_bit(const void *addr, int size, int
offset)
{
unsigned long *p = ((unsigned long *) addr) + (offset 5);
Why not const-qualify *p and the cast also (avoiding warnings and
actually making the change complete)?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, 2005-07-19 at 22:12 -0500, Matt Domsch wrote: On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote: [...] What you illustrated above is not going to work. If your doing #ifndef around a function, such as scsi_device_online, it's not going to compile when scsi_device_online is already implemented in the kernel tree. The routine scsi_device_online is a function, not a define. For a define this would work. Sure it does, function names are defined symbols. Defined for the preprocessor or the pure C-compiler or both of them? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a 15 GB file on tmpfs
On Wed, 2005-07-20 at 14:16 +0200, Bastiaan Naber wrote: [...] I have a 15 GB file which I want to place in memory via tmpfs. I want to do this because I need to have this data accessible with a very low seek time. Apart fromn the 32-vs-64bit thing: Isn't it enough (and simpler and more flexible) to mmap(2) that file and mlock(2) it afterwards? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a 15 GB file on tmpfs
On Thu, 2005-07-21 at 11:12 +0200, Stefan Smietanowski wrote: [...] On a 64bit machine: $ gcc test.c -o test64 ; ./test64; file ./test64 sizeof(void *): 8 sizeof(size_t): 8 test64: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped On a 32bit machine (or in this case, 32bit userland on a 64bit machine): $ gcc -m32 test.c -o test32 ; ./test32; file ./test32 sizeof(void *): 4 sizeof(size_t): 4 test32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped Meaning both the pointer and the size argument are only 32bit (4byte) on 32-bit arches and 64bit (8 byte) on 64bit arches. Which means that pure addressing of the 15GB on 32bit archs needs explicit handling (yes, you can manage the offset in a long long but you cannot index anything with it not addressable with a 32bit offset). Well, 64bit is apparently the way to go Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 10 GB in Opteron machine
On Fri, 2005-07-22 at 11:31 +0200, Christoph Pleger wrote: [...] 2. All other software on the machine is 32-bit software. Will that software work with a 64-bit kernel? Basically yes. E.g. open-office does not exist natively for 64bit architectuires ATM. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 10 GB in Opteron machine
On Fri, 2005-07-22 at 11:31 +0200, Christoph Pleger wrote: [...] 2. All other software on the machine is 32-bit software. Will that software work with a 64-bit kernel? Basically yes. E.g. open-office does not exist natively for 64bit architectures ATM (at least not on x86-compatibles). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel doesn't free Cached Memory
On Fri, 2005-07-22 at 08:27 -0300, Vinicius wrote: [...] I have a server with 2 Pentium 4 HT processors and 32 GB of RAM, this server runs lots of applications that consume lots of memory to. When I stop this applications, the kernel doesn't free memory (the memory still in use) and the server cache lots of memory (~27GB). When I start this applications, the kernel sends Out of Memory messages and kill some random applications. Anyone know how can I reduce the kernel cached memory on RHEL 3 (kernel 2.4.21-32.ELsmp - Trial version)? There is a way to reduce the kernel cached memory utilization? Probably RedHat's support can answer this for RHEL 3. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xor as a lazy comparison
On Sun, 2005-07-24 at 18:15 -0400, Puneet Vyas wrote: [...] I just compiled two identical program , one with != and other with ^. The assembly output is identical. Hmm, which compiler and which version? You might want to try much older and other compilers. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xor as a lazy comparison
On Tue, 2005-07-26 at 08:07 +0200, Jan Engelhardt wrote: [...] To answer for x *= 2 vs x = 1: and x += x Use * when you would logically want to do a multiplication, if you're working on a bitfield. It's just for keeping the code clean enough so that others may understand it. In the longshot, it does not matter, as gcc will optimize out multiplication ^^^ the C compiler with powers of two to bitops. And if the C compiler is not doing this properly, such tunings are probably in 100%-\eps cases worthless anyway. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] signed char fixes for scripts
On Thu, 2005-07-28 at 11:02 +0100, Paulo Marques wrote:
J.A. Magallon wrote:
On 07.27, Sam Ravnborg wrote:
On Fri, Jul 15, 2005 at 10:14:43PM +, J.A. Magallon wrote:
On 07.16, J.A. Magallon wrote:
On 07.15, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
This time I did not break anything... and they shut up gcc4 ;)
I have applied it to my tree. There still is a lot left when I compile
with -Wsign-compare.
All the problems are born here:
struct sym_entry {
unsigned long long addr;
unsigned int len;
unsigned char *sym;
};
What are you guys talking about?
unsigned char * is simply the wrong type for mere text strings. char
* ist the corrrect one. These are BTW two completely different types
(yes, char can be promoted into an unsigned char but essentially
these are two completely different types like int and long long *).
Is my compiler version the problem (3.3.2), or are you testing with the
Compiler version - zse gcc-4.*.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] signed char fixes for scripts
On Thu, 2005-07-28 at 11:40 +0100, Paulo Marques wrote: [...] You're comming really late in this thread :) Well, the same issue arised recently somewhere else too on this list and lots of C programmers (not only beginners) don't know about the 3 char types as speficied in the C standard. [ The C standard may have got problems recently with the real world usinf UTF-8 for a printable character but this must be solved elsewhere. ] The problem is that sym isn't really a string. It starts out as a string, but as the compression scheme begins to work it just becomes a bunch of bytes using all the values in the range 0-255 for which unsigned char is the perfect type. Since only the loading of the symbols use string functions, and all the compression process treats these as bytes, it seemed better to treat them as unsigned chars and just typecast the first few uses. ACK. The union suggested by J.A.Magallon might be a reasonable solution, but Syntactically yes. Conceptually no IMHO. sizeof(char) must be == sizeof(unsigned char) and must have the same alignment. So a cast seems to be the simpler and cleaner solution. we only need 4 casts in the 500 lines of code of scripts/kallsyms.c to solve all problems, so this seems really overkill. Is my compiler version the problem (3.3.2), or are you testing with the Compiler version - zse gcc-4.*. Yes, I know J.A.Magallon is trying to silence the warnings of gcc 4.0, but as I understood it, gcc 3 would also complain of the same problems if -Wsign-compare were specified. It was just that gcc4 would complain even without -Wsign-compare. AFAIK applies -Wsign-compare in gcc-3 only to pure compares (, , ...) and not assignments/passed parameters too. So the question is: is gcc4 complaining about signedness problems that gcc3 doesn't, even with -Wsign-compare? Now that I look at the source, I can see that it must be complaining! There are still 3 calls to strcmp that use sym directly, and gcc3 doesn't say a thing. As above - this will probably be silently promoted by gcc-3. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: United States Patent: 6,862,609]
On Thu, 2005-03-03 at 13:11 -0700, Trever L. Adams wrote: [...] It is Article 1 Section 8. It also says they shall have that power and that the intent is to promote the advances of arts and sciences. It Actually the current (ab)use of the patent system (both in the USA and by the EPO under pressure of you-know-who) does neither of these things - it simply promotes the *commercial exploitation* of sciences and art. Interesting enough that arts are mentioned in this thread - one more point that it is a question of time until all (other) kinds of arts is covered by patents (probably because you can do it on a computer). doesn't say that patents are the methods to be used. It doesn't say 17 years (or the whole 70/life+75 crap for copyrights). I think many very The 17/20 years for patents are also defined in TRIPS - so changing these to some saner value (given the speed of development in the IT world) is not an option (as pointed out by all patent-promoters at all opportunities). intelligent people have and will show that allowing patents on ideas (software patents are only this) tend to destroy such advances. ACK. And it is even worse: Currently the whole patent system is abused and there is no regulation in sight (since neither the patent offices nor large corporations have anything to loose with illegal/trivial/priort art/... patents). Yeah, yeah, from time to time there is someone who seems to show that they help... however, 90% of those seem to be backed by MS or SCO. They help if you can pay your lawyer. This leaves corporations in the game and the rest (small and medium companies, private folks) is lost - sooner or later. And BTW the bigger problem than software corporations (which can be sued since they are violating lots of these software patents) are the patent utilization companies which simply posses patents and (must) make money of it. And this implies going to the court (or you pay beforehand - since you/your company probably have no chance anyway to pay all the costs - to avoid this). Until this abuse is stopped, the patent system as a whole has a serious problem. Interesting considering many people, including Bill Gates, said quite differently in the past. IIRC he's now promising lawsuits (under certain conditions) with patents - at least to Asian governments. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Atheros wi-fi card drivers (?)
On Mon, 2005-03-07 at 16:55 +0100, Raphael Jacquot wrote: [...] as your name appears european, there are no software patents (yet ?) so Alas, this is wrong. The EPO is issuing masses of software patents since years (though they are more or less explicitly[0] excluded from patentability in the EPC). So they must not have been granted in the first place - nevertheless they are there. you should be able to release that code as required for interoperability however, IANAL Me too! Bernd [0]: Depending on how to interpret the words software as such. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uninterruptible sleep lockups
On Tue, 2005-02-22 at 22:05 -0300, Horst von Brand wrote: Chris Friesen [EMAIL PROTECTED] said: [...] Maybe I'm on crack, but would it not be technically possible to have all resource usage be tracked so that when a task tries to do something and hangs, eventually it gets cleaned up? Sure. But there is /no way/ to know if the task will ever do something (Turing's undecibility sees to that, even with perfect hardware), so the ACK. But if root says it will not come (through whatever method), the we have a decision good enough for real life. The downside is that we need for each usage of these items explicit checks and cleanup code (which wants to be written and tested) after each usage. Does this pay off? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: United States Patent: 6,862,609]
On Wed, 2005-03-02 at 21:28 -0700, Jeff V. Merkey wrote: Gene Heskett wrote: On Wednesday 02 March 2005 21:36, Jeff V. Merkey wrote: Another Linux patent. ... and another - AFAICS obvious - trivial (prior art) patent (but I'm not fluent in patent quak, I'm just a simple systems engineer). And one more reason to sent the European software patent directive simply to hell, clarify in §52.2 to not patentability of software discarding the word play of the patent attorneys and offices and get into the head of the folks of the EPO (with whatever means are necessary). And that pretty much says it. Assigned to the Canopy Group. So SCO will have yet another lawsuit to threaten us with. If they survive Apparently Canopy Group/SCO/... are not of the front of innovation since what is new on a RAID system in any way in 2005? the thrashing I've Been Moved will give them at the end of the day. The way to fight the patents is for Linux developers to file their own and start putting down stakes. Or simply drop the whole patent system as such. Apparently it is only abused to make money of the inventions of others and for sure does not help innovation as such in any way (it may help the lawyers, offices and companies in that area - patent utilisation - to get rich but that area has nothing to do with innovation). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: United States Patent: 6,862,609]
On Thu, 2005-03-03 at 01:21 -0500, Gene Heskett wrote: [...] It brings up another sore point with me. I'm of the opinion that both copyright, and patent, should be granted to the author/inventor on a non-transferable basis. He could then sell rights to use it for a ACK. This would kill the abuse and do what lots people are claiming - help the actual innovator (and not only help the patent abuse machinery). BTW in Austria and Germany (and probably the rest of continental Europe) the local version of the copyright (in german Urheberrecht) has this feature since ages. So just move onto here and voila, you there in at least this point. set period of time, at the end of which it is still his. The present, sell it to the highest bidder situation too often leaves talented folks in the soup lines at the local mission because they were screwed out of the benefits their invention or composition should have brought them. [...] Talk to the USPTO, they created these links from their website. BTW, Does USPTO sent the mail? No. if you check the verson of web server run on the uspto.gov server, you will discover it is Apache on IBM servers and IBM Linux. Ask them why IBM's sofware outputs links this way. And who sent it that broken way? Correction Jeff, you sent that link to the list, and IMNSHO, it was your job to see to it the mimetype was properly set. It was not. ACK. PEBKAC without doubt. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: creating daemons
On Wed, 2005-02-02 at 15:24 +0530, root wrote: i want run my program as a daemon..its like normal how to do that service squid start Look into /etc/init.d/squid (or wherever your distribution puts the SysV-Init startup files) on how to write a similar script for your daemon. And BTW this has nothing to do with the Linux *kernel*. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Patents
On Mon, 2005-01-17 at 08:44 -0500, linux-os wrote: Tue Jan 11 07:07:40 EST 2005 IBM has announced that it will provide free access to about No, they only promise now to not sue anyone given the following criteria. No one knows what happens in 5 years. 500 of its existing software patents to users and groups They have ca. 4 AFAIK. So 500 is 1,25 %. And IBM is actually lobbying for patents so this is only a marketing thing. working on open source software. http://www.ibm.com/news/us/ Many of these patents relate to interoperability, communications, file-export protocols, and dynamic linking. And almost all of them are pure software-patents and probably prior art. Thus they are - at least in Europe - not relevant and actually illegal if you believe in the current European patent law as defined by the European Patent Convention (see §52(2) for details). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM Patents
On Tue, 2005-01-18 at 09:37 +0100, Bernhard Schauer wrote: And almost all of them are pure software-patents and probably prior art. Thus they are - at least in Europe - not relevant and actually illegal if you believe in the current European patent law as defined by the European Patent Convention (see §52(2) for details). Hopefully nothing will change in future! Except the European Patent In terms of above statement, yes. It actually needs means to seriously control the EPO and national POs - there absolutely no independent justice (similar to other democratic systems) there. Nevertheless the evil propaganda was working since years to get the decision makers (read: law and politics folks with (almost) no knowledge of programming, software and/or copyright/author's rights) to believe in monopolies on ideas are good for small companies. And there are other forces pushing in that direction but without prove I won't speak about it Office should stop to give away software patents (even if they have no legal basis). From a juristical point of view (and they are actually saying that) they are legal (since they are granted) - even there are severe concerns (read: there are not fulfilled in any way) about the preconditions. However the POs get more money from granted patents than from not granted ones (for actually less work - for the patent proving person it is more work to seriously explain a declined patent instead of - more or less - simply accepting it) and the POs have absolutely no risk. Guess what will happen . Bernd, stopping now since it is quite off-topic here -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: time
On Thu, 2005-08-25 at 09:54 +0530, raja wrote: [...] Is There Any function in c to caliculate the exact time taken to execute block of code(in micro sec and milli sec and minuits and hours). thanking you, Do you mean system-time, user-space-time or the time it took in the real world? And apart from the fact that this is a C programming question and not directly related to the Linux kernel since it is a user-space thingy, you probably want to use times(2) two times and calculate the difference. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Petition for gas grices
On Thu, 2005-08-25 at 15:01 -0400, Patrick McFarland wrote: [...] cheap even if gas is $5 per gallon (predicted price for 2006). Better than We have here (in Austria/Europe) ATM 1.11 € for one liter of 91 Octane gasoline. Diesel oil is slightly (a few Cents) less. And it will probably rise further. Even if I calculate a gallon with 3.78 liters it is less Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A Great Idea (tm) about reimplementing NLS.
On Thu, 2005-08-25 at 20:00 -0400, Daniel B. wrote: Alan Cox wrote: On Sul, 2005-06-19 at 18:55, Pavel Machek wrote: [...] If we are serious about utf-8 support in ext3, we should return -EINVAL if someone passes non-canonical utf-8 string. That would ironically not be standards compliant Which standards? Probably POSIX, SuSv3 and similiar. The standards I've read (mostly XML- and web-related specs) do say that non-standard UTF-8 octet sequences should be rejected. There you have basically text files with some structure in it and the definiton/requirement that is is UTF-8. At kernel level these are also just byte streams and the kernel doesn't know or care which charset, encoding, file format, font etc. the data is used with or interpreted several layers higher, e.g. for presenting to the user. And the same holds for filenames. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: syscall: sys_promote
On Mon, 2005-08-29 at 11:55 +0800, qiyong wrote: Erik Mouw wrote: On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: I just wrote a tool with kernel patch, which is to set the uid's of a running process without FORK. The tool is at http://users.freeforge.net/~coywolf/pub/promote/ Usage: promote pid [uid] I once need such a tool to work together with my admin in order to tune my web configuration. I think it's quite convenient sometimes. The situations I can image are: 1) root processes can be set to normal priorities, to serve web service for eg. Most (if not all) web servers can be told to drop all privileges and run as a normal user. If not, you can use selinux to create a policy for such processes (IIRC that's what Fedora does). In this way, it's that the web servers themselves drop the privileges, not forced by sysadmin. sys_promote is a new approach different from The sysadmin selects the tool and writes the configuration file. So for the purpose of this discussion, it is effectively the same. selinux or sudo. sys_promote is manipulating a already running process, while selinux or sudo is for the next launching process. Kill the process and start it again. Problem solved. 2) admins promote trusted users, so they can do some system work without knowing the password Use sudo for that, it allows even much finer grained control. sudo may become a security problem. Sysadmin and the user don't like (almost) every tool may become a security problem. If you fear a bug in sudo, then write a minimal setuid wrapper for yourself which checks for the user it started and exec's a binary (with the full path name specified). And even then - dependent on other details of the setup - you have the gap of security problems (or misuse) because of holes in the security. the user's account always have priorities. My sysadmin Hommel says this to me: What does the user do if the process terminates (for whatever reason) and must be restarted by the user (manually or auutomatically)? Basically I can see no need for one time in history actions. A daemon can terminate and must be restarted (it may even be a software bug that causes this and this doesn't change anything that the daemon's admin must restart it *now*). The machine may reboot for whatever reason Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: syscall: sys_promote
On Mon, 2005-08-29 at 16:16 +0800, Coywolf Qi Hunt wrote: Bernd Petrovitsch wrote: [...] (almost) every tool may become a security problem. If you fear a bug in sudo, then write a minimal setuid wrapper for yourself which checks for the user it started and exec's a binary (with the full path name specified). And even then - dependent on other details of the setup - you have the gap of security problems (or misuse) because of holes in the security. But if we make sure a tool doesn't introduce any new secrutiy problem, that's good enough. ACK. That's basically the idea behind write 15 lines of C code and be absolutely sure that there is no problem in there. [...] What does the user do if the process terminates (for whatever reason) and must be restarted by the user (manually or auutomatically)? If we worry that, we'd make a persistent OS instead. Basically I can see no need for one time in history actions. A daemon can terminate and must be restarted (it may even be a software bug that causes this and this doesn't change anything that the daemon's admin must restart it *now*). The machine may reboot for whatever reason The US space shuttle certainly can auto pilot, so it doesn't need a control panel. And If anything fails, NASA just launch another ship? I didn't realize that you are working on (one-time) Space Shuttle software. I assumed average servers, services and environment Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KLive: Linux Kernel Live Usage Monitor
On Tue, 2005-08-30 at 11:40 +0200, Rogier Wolff wrote: [...] would IMHO work better. (A userspace program is technically a better solution, the social aspect of getting a bigger user-base is the main reason for me to suggest the in-kernel approach). So *if* a user wants to participate, he/she also installs and configures some daemon for this (which is also easier to look into if one is curious) and there is no Linux kernel phones home stories. And if not, he/she can easily remove it (again). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
On Wed, 2005-08-31 at 18:56 -0600, jmerkey wrote: Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: I mean, nvidia people also use propietary code in the kernel (probably violating the GPL anyway) and don't do such things. The Linux kernel allows binary drivers, you just have to live with a limited number of exported symbols and that the kernel is tainted. Which basically means nobody sane can help you with corrupted kernel data structures. [...] Thanks for the accurate and reasonable response. I object to the use of the word tainted. This implies the binary code is somehow infringing. I would suggest changing the word to It is infringing the debuggability seriously outside the exclusive club of people with access to the secret source of these drivers. So tainted pretty much explains quite well the situation as seen from the kernel side. non-GPL or Vendor Supported since this is more accurate. Just a suggestion. non-GPL is clearly wrong. First the kernel source it self stays GPL independent for whatever legal people write into othre license agreements, second the license of your source *could be* (in theory) GPL if the authors wanted it and - in some cases - the source *is* actually GPL even if the authors doesn't want it. And Vendor supported must be (if you really want to be accurate) At best it is vendor supported if the vendor exists at the moment and for whatever said vendor thinks support is. The contact address for said vendor is name, street, phnoe, mobile, email, homepage. Please do not ask the free software community if you have any problem with the Linux kernel. So please put this in your proprietory module and print it whenever it makes sense since the necessary contact data is only known by you. The point is: There is no such concept as vendor as it would or could be seen in the commercial and/or legal world if you download the kernel source from kernel.org. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forbid to strace a program
On Sun, 2005-09-04 at 09:32 +0200, Andreas Hartmann wrote: Chase Venters wrote: [...] Can I ask why you want to hide the database password from root? It's easy: for security reasons. There could always be some bugs in some software, which makes it possible for some other user, to gain root privileges. Now, they could easily strace for information, they shouldn't Forget it. You cannot hide anything seriously from root (or equivalent users on other OSes and so-called OSes) with such attempts (independent how the process got root - with the correct password or through a security hole somewhere). Consider the case that root installed a (patched) DB-server which dumps the passwords in some logfile. Or root logs from the authentication framework (be it PAM or something else) could do it. The password they could see, isn't just used for the DB, but for some other applications, too. That's the disadvantage of general (single sign on) passwords. So either you get your own machine or you use different passwords for different services. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Fri, 2006-12-22 at 12:59 +0100, Erik Mouw wrote: On Thu, Dec 21, 2006 at 01:16:15PM -0500, [EMAIL PROTECTED] wrote: At least nVidia *does* actually Get It, they just don't have a choice in implementing it, because all their current hardware includes patents that they licensed from other companies (I believe some of the OpenGL stuff that originated at SGI and got bought by Microsoft is involved, but I have no hard references for actual patent numbers). And then they have the big problem - do they keep using the patent in order to boost performance, or no? Wasn't the whole idea about patents that you publish your invention? Of course. But it is much better for the patent-interested parties if it wouldn't be necessary (and said parties are actually complaining about the must publish thing). And the times are long gone when a patent was actually publishing. They use since ages there own secret language so - the patent system as such doen not enforce publisching (except you are one of speakers of patent quak). - that even the most trivial idea looks like it is very complicated. - that even an already implemented idean looks like it is very new. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
On Thu, 2006-12-28 at 09:54 +0100, Jan Engelhardt wrote:
On Dec 27 2006 17:10, Pavel Machek wrote:
Was just wondering if the _var_ in kfree(_var_) could be set to
NULL after its freed. It may solve the problem of accessing some
freed memory as the kernel will crash since _var_ was set to NULL.
Does this make sense? If yes, then how about renaming kfree to
something else and providing a kfree macro that would do the
following:
#define kfree(x) do { \
new_kfree(x); \
x = NULL; \
} while(0)
There might be other better ways too.
snip
(x) = NULL; \
snip
?
No, that would be very confusing. Otoh having
KFREE() do kfree() and assignment might be acceptable.
What about setting x to some poison value from linux/poison.h?
That depends on the decision/definition if (so called) double free is
an error or not (and free(NULL) must work in POSIX-compliant
environments).
Personally I think it is pointless to disallow kfree(NULL) by using
some poison value and force people to add a we have to free that
variable variable to work around it instead of keeping it NULL (which
makes the kfree($variable) a no-op).
Former discussions are to be found in the archives ..
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Tue, 2007-01-02 at 16:30 +1000, Trent Waddington wrote: [...] I think you're repeating a myth that has become a common part of hacker lore in recent years. It's caused by how little we know about software patents. The myth is that if you release source code which violates someone's patent that is somehow worse than if you release binaries that violate someone's patent. This is clearly, obviously, false. If you're practising the invention without a license in your source code then you're practising the invention without a license in binaries compiled from that source code. Period. While this is true (at last in theory), there is one difference in practice: It is *much* easier to prove a/the patent violation if you have (original?) source code than to reverse engineer the assembler dump of the compiled code and prove the patent violation far enough to get to a so-called agreement on the costs. Nvidia are not releasing source code to their drivers for one reason: it's not their culture. They don't see the need. They don't see the benefit. Which also may well be true. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Tue, 2007-01-02 at 21:26 +1000, Trent Waddington wrote: On 1/2/07, Bernd Petrovitsch [EMAIL PROTECTED] wrote: While this is true (at last in theory), there is one difference in practice: It is *much* easier to prove a/the patent violation if you have (original?) source code than to reverse engineer the assembler dump of the compiled code and prove the patent violation far enough to get to a so-called agreement on the costs. On 1/2/07, Alan [EMAIL PROTECTED] wrote: You are forgetting the 11th commandment - thou shalt not get caught. Most software patents (actually quite probably most patents) are held by people who don't have the skills to go disassembling megabytes of code in search of offenders. The list of features which the driver supports is going to be sufficient evidence for 99% of patents that relate to computer graphics hardware. Regardless, in the *millions* of dollars that it costs to prosecute a patent violation case I think they can find a few grand to throw at a disassembler jockey. Most of the cases (more or less almost all AFAIK) are handled/closed without really going to court (since it is cheaper for all - especially if the alleged patent violator is substantially smaller than the patent holder and will not survive the law suit. See it as protection money). So there are no real statistics available on this issue. I don't know about others but I wouldn't write an offer with a fixed price for look into assembler dumps, reverse engineer it and find an infringement on a list of given patents so the patent holder has to list the patents and the amount of my time to invest (and then he will get a price for it and no guarantees of success). Thus the patent holder takes the whole risk that I don't find anything useful (independent of the presence of a patent violation or my inability to find/identify it). And you need people wo are literate in patent quak and the technical side so it will IMHP not work if you get someone not very expensive[0]. So I'll take back what I said.. it does make some difference whether you release patent violating source code or patent violating binaries. It makes about a 1% difference to the overall cost of prosecuting a patent lawsuit. Given the above, the difference (measured in money/effort/) is in IMHO much larger than 1%. Now if you are done speculating why nvidia might have a reasonable reason for not releasing source code, can we just take it as read that the most likely reason is that they simply don't want to because they don't see the benefit? If that's the case, what benefit can we offer them? I don't know. For network cards it helped to recommend hardware with open drivers. In the graphic card department this didn't worked up to now. Bernd [0]: That doesn't imply that hiring someone expensive guarantees success. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Tue, 2007-01-02 at 16:23 -0300, Horst H. von Brand wrote: Bernd Petrovitsch [EMAIL PROTECTED] wrote: [...] I don't know about others but I wouldn't write an offer with a fixed price for look into assembler dumps, reverse engineer it and find an infringement on a list of given patents so the patent holder has to list the patents and the amount of my time to invest (and then he will get a price for it and no guarantees of success). And them you'd have to testify (as an expert witness, AFAIU). Having Probably if -) I actually found something and -) the patent holder also believes in it (and he will - IMHO very probably - pay another expert to verify the findings) and -) the patent holder actually persues the infringements and -) the law suit goes that far and. legally demostrable expertise in the area isn't easy, I suppose. At least in .at you need some kind of official approval to become an expert in court (in German: Gutachter - Is assessor the correct translation? http://dict.leo.org/ lists 9 different words). Actually this is a somewhat different job Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux, Get the facts?
On Tue, 2005-08-02 at 14:19 -0600, Alejandro Bonilla wrote: [...] I watched some commercials and I almost puked when I looked at the Microsoft Get the Facts for Linux vs Windows Server stuff. They have a url which is http://www.microsoft.com/getthefacts Yes, this propaganda exists since months. Is this crap any close to real or by any chance realistic ? Are these benchmarks simple marketing? Would you expect anything on *that* server? Hey, they must sell that stuff. Everything else is not important. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
On Fri, 2006-12-15 at 21:20 +, James Porter wrote: I think some kernel developers take to much responsibility, is there a bug in a binary driver? Send it upstream and explain to the user that it's a closed Plaese name them. AFAICS if there is a response, it is similar to your kernel is tainted, please report the report elsewhere. source driver and is up to said company to fix it. For what it's worth, I don't see any problem with binary drivers from hardware manufacturers. You are probably not looking at the right places. Just because nvidia makes a closed source driver doesn't mean that we can't also ^^ Please send patches. create an open source driver(limited functionality, reverse engineered, etc.,etc.). I firmly believe that the choice should be up to the user and/or distro. I'm not a kernel dev, I don't know c...but I understand the concepts and ^^ Then become one if you are serious with the we above. I should have the right to do what I want with this GPL code. Restricting me Then you should discuss this with law makers, politicians and the various pressure groups about copyright and/or authors rights and you surely *must* deal beforehand with the patent plague since this is even more restricting in any sense than author rights ever was (let alone copyright). And for such political debate LKML is probably not a good place. only frustrates me. Should the default be open source, definitely; should binary drivers be blocked from running on a linux kernel...certainly not. They are not blocked - it is up to the users to decide and live with the consequences. [...] only to have the rug pulled out from under you. This is what makes the BSDs so attractive. Why are you then here? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Wed, 2006-12-20 at 16:38 -0800, Casey Schaufler wrote: [...] The argument that a hardware company usually invokes is that, while they don't give a horse's pitute about the software itself, they do care about the information the software contains about their hardware. The concern is that publishing the software under any form of open or free license would be seen as publishing the details of the hardware, thus making any claims that they attempted to protect thier intellectual property void. They would sell less hardware because they would have no legal recourse against anyone who stole the secrets to their hardware. The more realistic and more expensive threat is not the above (yes, one can copy an already released product after reverse enginnering and also try to sell it but how long - in calendar time - does this take? And during that time the original is sold all the time) but it is much easier to detect (real or potential) patent violations and the fun begins probably. And ATM is is practically not possible to build anything remotely technical without violating hundreds of patents somewhere (they may be legal or illegal or trivial or software as such but if a patent is granted it is there). I make no claims to understanding the legal basis for this position. I don't even know if I think it makes sense. I have heard it often enough to understand that many people believe it though. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: KB-KiB, MB - MiB, ... (IEC 60027-2)
On Mon, 2007-01-22 at 02:56 +0100, Krzysztof Halasa wrote: Jan Engelhardt [EMAIL PROTECTED] writes: Bleh. Except for storage, base 1024 was used for almost everything I remember. 4 MB memory meant 4096 KB, and that's still the case today. Most likely the same for transfer rates. Nope, transfer rates were initially 1000-based: 9.6 kbps = 9600 bps, 28.8 kbps = 28800 bps, 64 kbps = 64000 bps. Then it went 128, 256, 512 kbps = 512000 bps and 1 Mbps = 2 * 512 kbps = 1024000 bps. ACK. But this and harddisk sizes are really the only areas. But it's limited mostly to serial interfaces. Other networks use 10, 1000 etc. because they have nothing natural in (powers of) 2 so 1 Mbps may be 100 bps as well. It's just that storage vendors broke the computer rule and went with 1000. 1024 etc. is (should be) natural to disks because the sector size is 512 B, 2048 B or something like that. Yes, but it sounds in commercials better if there is a larger number there. And you can raise the result of a fraction if you lower the divisor. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mark bitrevX() functions as const
On Mon, 2006-12-11 at 18:35 +0100, Jan Engelhardt wrote: [...] I can just second this. What should be marked const is [1]the things pointed to, not [2]the local copy of a function argument. This[2] is what I believe almost every other software project does, Yes, also for the reason to educate people to actually use const as much as possible - if only to make it for humans clear what may change somewhere and what not. though they often fail at [1]. Or have you seen Glibc trying to pull a int strtoul(const char *const nptr, char **const endptr, const int base)? It just makes the prototypes and headers longer without having glibc functions like strtoul() are an extremely bad example for this because there are standards out there which the define the function signature - so it is often not really the choice of some glibc developer/maintainer/project lead. Or you have very old implementations like e.g. the RPC/XDR library which simply ignore the const keyword. too much benefit. And maybe the code author may even want to reuse the args directly as walking pointers or countdown integers, for example. And that is the other problem of such functions and C as such: One wants the const char * in the argument list (if possible) since it allows to pass const char * and char *. The return value should similarly be char * because then you can use it in the above mentioned way for const char * and char *. Alas that gives you a chance to cast const char * to char * and not even trigger a compiler warning (as opposed a real type cast). Of course this can be handled/fixed by review but it takes people to actually do this. The only sane solution is to get out the same const-ness as passed in - but this is syntactically not possible in plain simple C. And the above paragraph is not arguing to remove the keyword const. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 18:47 +0100, Hans-Jürgen Koch wrote: Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch: On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote: [] A small German manufacturer produces high-end AD converter cards. He sells 100 pieces per year, only in Germany and only with Windows drivers. He would now like to make his cards work with Linux. He has two driver programmers with little experience in writing Linux kernel drivers. What do you tell him? Write a large kernel module from scratch? Completely rewrite his code because it uses floating point arithmetics? Find a Linux kernel guru/company and pay him/them for -) an evaluation if it is better (for whatever better means) to port the driver or write it from scratch and -) do the better thing. Good idea - whatever porting means. There are lots of Windows drivers out there Yes, I didn't want to open that can of worms. that are also partly user space using that Kithara stuff. They have most of their driver in a dll. So that is similar to what we want with UIO - except that we handle interrupts in a clean way, they don't. If you need to port such a driver, simply writing a kernel module and a user space library would change so much of the concept that you can start rewriting it from Of course, if better means as cheap as possible no matter what, this is probably the way to go. Tough luck if you get into technical problems . scratch. And you'll have a large kernel module to maintain. OK, the guru/company can earn money with it, at least as long as the customer doesn't realize it is not the best solution for him. Depending on the definition of best. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote: [] A small German manufacturer produces high-end AD converter cards. He sells 100 pieces per year, only in Germany and only with Windows drivers. He would now like to make his cards work with Linux. He has two driver programmers with little experience in writing Linux kernel drivers. What do you tell him? Write a large kernel module from scratch? Completely rewrite his code because it uses floating point arithmetics? Find a Linux kernel guru/company and pay him/them for -) an evaluation if it is better (for whatever better means) to port the driver or write it from scratch and -) do the better thing. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what will connect the fork() with its following code ? a simple example below:
On Tue, 2005-09-06 at 17:15 +0800, Sat. wrote:
if(!(pid=fork())){
..
printk(in child process);
..
}else{
.
printk(in father process);
.
}
this is a classical example, when the fork() system call runs, it will
build a new process and active it . while the schedule() select the
new process it will run. this is rather normal.
but there is always a confusion in my minds.
because , sys_fork() only copies father process and configure some new
values., and do nothing . so the bridge between the new process and
its following code, printk(in child process), seems disappear . so I
No, it is the same point as in the parent process - just the fork()
call. In fact the fork() returns twice - once within the parent process
(returning as result the pid of the child) and once within the child
(returning 0) [ and we ignore the error case for simplicity ].
Basically you are not forced to do a if() or switch() on the return
value(s) of fork()
snip
printf(1. fork() in process %d returned %d\n, getpid(), fork());
printf(2. fork() in process %d returned %d\n, getpid(), fork());
printf(3. fork() in process %d returned %d\n, getpid(), fork());
printf(4. fork() in process %d returned %d\n, getpid(), fork());
printf(5. fork() in process %d returned %d\n, getpid(), fork());
snip
Put this in a main() function and try it out.
always believe that the new process should have a pointer which point
the code printk(in child process);. except this , there are not
any connection between them ?
The kernel doesn't know (or care) about the C code (e.g. if(), ...) in
your application.
The pointer (if you want to call it) is the normal instruction pointer
(or what else it is called on your CPU).
very confused :(
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild C++
On Tue, 2005-09-06 at 13:23 +0200, Budde, Marco wrote: [] for one of our customers I have to port a Windows driver to Linux. Large parts of the driver's backend code consists of C++. How can I compile this code with kbuild? The C++ support (I have tested with 2.6.11) of kbuild seems to be incomplete / not working. Yes, because the official Linux kernel is pure C (using some gcc extensions). There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is a) not integrated (and will probably never) and b) you can't use parts of C++ anyway with it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild C++
On Tue, 2005-09-06 at 17:08 -0400, Chris Frey wrote: On Tue, Sep 06, 2005 at 01:30:34PM +0200, Bernd Petrovitsch wrote: Yes, because the official Linux kernel is pure C (using some gcc extensions). There is http://netlab.ru.is/exception/LinuxCXX.shtml but it is a) not integrated (and will probably never) and b) you can't use parts of C++ anyway with it. All the language features are supported, according to them. The standard library is not available that I can see, but it's not available in C either, in the kernel. ACK (and the few necessary equal or similar functions of the standard C lib are implemented directly). It depends on the to-be-integrated C++ source if it is clean enough from these features (let alone from Win* specific stuff) so that it makes sense to really integrate it (so that future versions can replace it more easily) and just convert it to pure C (which may be less work now but more of a maintenance headache). And no, I don't think that building a windriverwrapper (a la ndiswrapper) is a useful thing. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what will connect the fork() with its following code ? a simple example below:
On Tue, 2005-09-06 at 12:58 -0400, [EMAIL PROTECTED] wrote:
On Tue, 06 Sep 2005 17:15:51 +0800, Sat. said:
Not a kernel problem, please consult an intro-to-C list next time
if(!(pid=fork())){
..
printk(in child process);
..
}else{
.
printk(in father process);
.
}
values., and do nothing . so the bridge between the new process and
its following code, printk(in child process), seems disappear
I'm assuming you actually meant printf() (which is the userspace stdio call)
rather than printk() (which is the inside-the-kernel variant).
I actually assumed the same.
'man setbuf' - most likely the output of the child process is buffered and
never actually output before it exits. You want to set stdout to be
It is buffered since the above printf() lacks a terminating \n. So
either put a \n at the end or call fflush(stdout);
line-buffered or unbuffered, or write to stderr (unbuffered by default) rather
than stdout.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: kbuild C++
BTW you kill threading. On Wed, 2005-09-07 at 11:13 +0200, Budde, Marco wrote: [...] That would be because the kernel is written in *C* (and some asm), *not* C++. I cannot see the connection. At the end everything gets converted to assembler/opcode. In the user space I can mix C and C++ code Yup. And exported symbols for the linker. without any problems, why should this not be possible in the Yes, this is a general problem with integrated c/c++ stuff like Win-Visual C++. People think that they can mix it freely, in fact they are using *only* C++ (it just happens that some part of the source is compilable with a C compiler, but since you compile everything with the C++ compiler pressing F9, no one sees the difference). Why do you think are all these #ifdef _cpluplus stuff in the header files for? kernel mode? Try linking also in the user space, not only compilation. Second read in the standards about the difference between hosted and standalone environments and think on the differences. There /is/ no C++ support. This will be a problem in future. Nearly nobody will start a new No. larger project (driver, user space software, embedded firmware) We re on linux-kernel@ here, so we don't care *here* for user-space software (only for the interface - i.e. sys-calls). And for embedded usage C++ is unsusable in user-space too since it will ex-bloat the whole software if people simply pull-in usual and/or common C++ libraries like the STL and use them without knowing how much object code they explode with it (if used without thinking). using non OO languages today. So porting eg. Windows drivers to Which is again wrong. You can OO software without OO languages (though you loose some nice features and checking). Linux is nearly impossible without C++ support. Is is impossible anyways since the in-kernel interfaces are probably quite different (though I don't know anything about ). E.g. in my case the Windows source code has got more than 10 MB. Nobody will convert such an amount of code from C++ to C. This would take years. First, how much of it is really the source of a kernel driver (in the sense of a Unix/Linux kernel driver)? And second, no one expects that you convert your driver source. Just write it from scratch (since you know the internals of the hardware quite well it should take only a few weeks). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
