Re: 2.6.25-rc1/2 CD/DVD burning broken
Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >This fragment is much too short to allow to judge on possible reasons. > >There is a high probability that your problem is caused by the cdrecord > >fork called "wodim". > > > [...] > > > >As a general advise: if you have problems, always first try recent original > >software from > > SUSE 10.3 users (and the OP seems to be one..) may use the 'cdrtools' > RPM which I have in my repository (I don't like wodim either, but that's > not the point here). Just !webpin for cdrtools. Thank you for this hint! Maybe, you should mention a URL to your repository > (oh and please use reply-to-all/dont-strip-Ccs, thanks :) For me too please Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- 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: 2.6.25-rc1/2 CD/DVD burning broken
Jan Engelhardt [EMAIL PROTECTED] wrote: This fragment is much too short to allow to judge on possible reasons. There is a high probability that your problem is caused by the cdrecord fork called wodim. [...] As a general advise: if you have problems, always first try recent original software from SUSE 10.3 users (and the OP seems to be one..) may use the 'cdrtools' RPM which I have in my repository (I don't like wodim either, but that's not the point here). Just !webpin for cdrtools. Thank you for this hint! Maybe, you should mention a URL to your repository (oh and please use reply-to-all/dont-strip-Ccs, thanks :) For me too please Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- 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: 2.6.25-rc1/2 CD/DVD burning broken
> changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the > following error from wodim: > Errno: 0 (Success), write_g1 scsi sendcmd: no error > CDB: 2A 00 00 00 00 00 00 00 1F 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00 > Sense Key: 0x5 Illegal Request, Segment 0 > Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 > Sense flags: Blk 0 (not valid) > resid: 63488 This fragment is much too short to allow to judge on possible reasons. There is a high probability that your problem is caused by the cdrecord fork called "wodim". Please always include the following information in your bug-report: - The version number of cdrecord that caused the bug. - The command line that was used for the failing command. - The complete output (including error messages) from 'cdrecord -v ...' - Probably the important part of the 'cdrecord -V' output if we agreed on it - The OS name, release and hardware (processor) - Special conditions of your environment (libc vers. SCSI transport ...) - Sufficient information on the media used. This is at least the ATIP data, a note to CD-R/CD-RW and information on the state and the case history of this media. As a general advise: if you have problems, always first try recent original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ None of the 30+ bugs reported against wodim in various Linux distributions is known to be present with recent original software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- 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: 2.6.25-rc1/2 CD/DVD burning broken
changing ide-cd (take 4)] I cannot burn any CD/DVD any more, getting the following error from wodim: Errno: 0 (Success), write_g1 scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 Sense flags: Blk 0 (not valid) resid: 63488 This fragment is much too short to allow to judge on possible reasons. There is a high probability that your problem is caused by the cdrecord fork called wodim. Please always include the following information in your bug-report: - The version number of cdrecord that caused the bug. - The command line that was used for the failing command. - The complete output (including error messages) from 'cdrecord -v ...' - Probably the important part of the 'cdrecord -V' output if we agreed on it - The OS name, release and hardware (processor) - Special conditions of your environment (libc vers. SCSI transport ...) - Sufficient information on the media used. This is at least the ATIP data, a note to CD-R/CD-RW and information on the state and the case history of this media. As a general advise: if you have problems, always first try recent original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ None of the 30+ bugs reported against wodim in various Linux distributions is known to be present with recent original software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- 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] USB autosuspend fixes for 2.6.23-rc6
> That's true now, but it wasn't always. Until the last year or so, > cdrecord wouldn't work properly with USB CD drives having a 64-sector > limit unless the user added a particular command-line argument. This is a bug that is known since ~ 3 years and that has been fixed _very_ recently. It was still present in 2.6.21.7 a few weeks ago. And BTW: the limit was not 64 sectors but ~13 sectors. 64 sectors would be at least 128 kB but the limit was ~ 32k. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] USB autosuspend fixes for 2.6.23-rc6
That's true now, but it wasn't always. Until the last year or so, cdrecord wouldn't work properly with USB CD drives having a 64-sector limit unless the user added a particular command-line argument. This is a bug that is known since ~ 3 years and that has been fixed _very_ recently. It was still present in 2.6.21.7 a few weeks ago. And BTW: the limit was not 64 sectors but ~13 sectors. 64 sectors would be at least 128 kB but the limit was ~ 32k. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
DervishD <[EMAIL PROTECTED]> wrote: > Hi Joerg :) > > Do not try to replace one dead program by another one > > Do you mean cdrkit? Correct. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
DervishD [EMAIL PROTECTED] wrote: Hi Joerg :) Do not try to replace one dead program by another one Do you mean cdrkit? Correct. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
>It is probably about time that cdparanoia was updated ... >Doug Gilbert Cdparanoia was not updated since 2001. The here important low level code is still the same as with cdda2wav from 1997. For this reason, I did create a portable libparanoia from the assets of the cdparanoia code and also fixed several bugs in the paranoia code. We then added this code to a recent cdda2wav in April 2002. People need to learn that cdparanoia is dead and no longer maintained by Monty. Monty is working on other software now. A recent maintained version is here: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/new/private/cdrecord.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
>> It is probably about time that cdparanoia was updated ... >I think the same, but given that it works, Monty probably doesn't >have much motivation to update it. I don't know if the problem resides >in the cdparanoia program itself (so using the DAE problem from cdrkit >will fix the issue) or in the paranoia library. In this case, the >problem will affect any program using the library. Do not try to replace one dead program by another one If you like actively maintained software you need to look here: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/new/private/cdrecord.html The main problem with cdparanoia is that it is based on a 10 year old cdda2wav. Even if Monty did start working on it again, he would not change that. Sending bad SCSI commands is a result of bad low level code from an extremely old cdda2wav version. Libparanoia in cdrtools is based on the assets of the cdparanoia program. The software has been made portable and several bugs have been removed by me. BYW: The next plan with cdda2wav is to add C2-pointer support and to allow libparanoia to know whether a sector was bad or not even if a bad sector will re-read the same for every try. This will make cdda2wav behave better with extremely bad/scratched media. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
It is probably about time that cdparanoia was updated ... I think the same, but given that it works, Monty probably doesn't have much motivation to update it. I don't know if the problem resides in the cdparanoia program itself (so using the DAE problem from cdrkit will fix the issue) or in the paranoia library. In this case, the problem will affect any program using the library. Do not try to replace one dead program by another one If you like actively maintained software you need to look here: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/new/private/cdrecord.html The main problem with cdparanoia is that it is based on a 10 year old cdda2wav. Even if Monty did start working on it again, he would not change that. Sending bad SCSI commands is a result of bad low level code from an extremely old cdda2wav version. Libparanoia in cdrtools is based on the assets of the cdparanoia program. The software has been made portable and several bugs have been removed by me. BYW: The next plan with cdda2wav is to add C2-pointer support and to allow libparanoia to know whether a sector was bad or not even if a bad sector will re-read the same for every try. This will make cdda2wav behave better with extremely bad/scratched media. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: cdparanoia not setting count and/or reply_len properly
It is probably about time that cdparanoia was updated ... Doug Gilbert Cdparanoia was not updated since 2001. The here important low level code is still the same as with cdda2wav from 1997. For this reason, I did create a portable libparanoia from the assets of the cdparanoia code and also fixed several bugs in the paranoia code. We then added this code to a recent cdda2wav in April 2002. People need to learn that cdparanoia is dead and no longer maintained by Monty. Monty is working on other software now. A recent maintained version is here: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/new/private/cdrecord.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
Personal attacks (was Re: Linux Kernel include files)
Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > Jörg > [advertisements removed] Please stop this kind of trolling, you did not remove anything here, so do not claim to remove things As you don't seem to know the nettiquette: If you believe you have some kind of problems that was used by the OP to send a personal attack, the natural reaction is to send a personal mail that does _not_ include a list of persons or a mailing list. As it does not seem to make sens to continue here, I will not reply to any further mail that tries to discuss something from the "mail threading" attack. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Re: Linux Kernel include files
Willy Tarreau <[EMAIL PROTECTED]> wrote: > Jörg, > > On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote: > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: > > > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > By the way, your mailer seems to be sometimes omitting In-Reply-To: > > > > > and > > > > > References: headers, which RFC2822 says you SHOULD include in > > > > > replies. > > > > > > > > Sending such accusation without knowing the reason is not polite. > > > > > > It's not an accusation -- it's merely an observation. You may not have > > > noticed that your mailer was misbehaving; now you _do_ know, and if you > > > care about RFC compliance you might want to fix it. You're not _obliged_ > > > to fix it, of course. I just thought you'd like to know. > > > > Well there you are: my mailer is definitely NOT missbehaving. > > Please do not repeat similar accusations when not knowing the reason. > > Attacking people who suggest to you they *may* have noticed an anomaly is > not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Re: Linux Kernel include files
Willy Tarreau [EMAIL PROTECTED] wrote: Jörg, On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote: David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: David Woodhouse [EMAIL PROTECTED] wrote: By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. Sending such accusation without knowing the reason is not polite. It's not an accusation -- it's merely an observation. You may not have noticed that your mailer was misbehaving; now you _do_ know, and if you care about RFC compliance you might want to fix it. You're not _obliged_ to fix it, of course. I just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
Personal attacks (was Re: Linux Kernel include files)
Willy Tarreau [EMAIL PROTECTED] wrote: Jörg [advertisements removed] Please stop this kind of trolling, you did not remove anything here, so do not claim to remove things As you don't seem to know the nettiquette: If you believe you have some kind of problems that was used by the OP to send a personal attack, the natural reaction is to send a personal mail that does _not_ include a list of persons or a mailing list. As it does not seem to make sens to continue here, I will not reply to any further mail that tries to discuss something from the mail threading attack. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: Userspace compiler support of "long long"
Harald Arnesen <[EMAIL PROTECTED]> wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > Is there any userspace Linux compiler that does not support "long long"? > > If yes, is there any other way to tell that something is a > > 64bit int on 32bit architectures? > > TenDRA C: > > "test.c", line 6: Error: > [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. You cannot use this compiler for any program that uses an interface that needs long long. BTW: C99 requires long long but the Large File summit from 1995 did to the same since 1995. An 32 bit OS that supports large files cannot have a compiler that does not support long long. If TenDRA C does support 64 bit integral type in a different way. TenDRA C would need to deliver include files that take care about this fact. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> > from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
> > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
> > âs_next_generationâ
> > /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
> > /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
>
> Hi Jörg.
>
> For my test I used latest -git of the Linux kernel.
> In this version the include of ext2_fs_bh.h is guarded
> by __KERNEL__ like this:
>
> #ifdef __KERNEL__
> #include
> static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
> {
> return sb->s_fs_info;
> }
>
Thank you!
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
David Woodhouse <[EMAIL PROTECTED]> wrote: > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote: > > > > Warning: *** linux/ext2_fs.h is not usable at all *** > > > > Warning: *** This makes it impossible to support Linux file flags *** > > > > You may try to compile using 'make COPTX=-DTRY_EXT2_FS' > > > > > > Again, can you be _specific_? Amusing though your consistent 'Lunix is > > > broken' chants are, the only reason I'm bothering to participate in this > > > thread is on the off-chance that something _productive_ will come of it. > > > > I have been forced to add this test as too many people reported that they > > have no been able to compile star on their Linux distribution. > > But do you not know _why_? What exactly are you testing _for_? > > Bug reports which merely say 'is broken' are not helpful. If you like to know what I test, I encourage you to check the autoconf scripts. I am testing whether the named include file may be used from a user space program. As I did mention already, I was forced to add the test in order to be able to compile at all. > > > By the way, your mailer seems to be sometimes omitting In-Reply-To: and > > > References: headers, which RFC2822 says you SHOULD include in replies. > > > > Sending such accusation without knowing the reason is not polite. > > It's not an accusation -- it's merely an observation. You may not have > noticed that your mailer was misbehaving; now you _do_ know, and if you > care about RFC compliance you might want to fix it. You're not _obliged_ > to fix it, of course. I just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
David Woodhouse <[EMAIL PROTECTED]> wrote: > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote: > > Warning: *** linux/ext2_fs.h is not usable at all *** > > Warning: *** This makes it impossible to support Linux file flags *** > > You may try to compile using 'make COPTX=-DTRY_EXT2_FS' > > Again, can you be _specific_? Amusing though your consistent 'Lunix is > broken' chants are, the only reason I'm bothering to participate in this > thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. > By the way, your mailer seems to be sometimes omitting In-Reply-To: and > References: headers, which RFC2822 says you SHOULD include in replies. Sending such accusation without knowing the reason is not polite. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
David Woodhouse [EMAIL PROTECTED] wrote: On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote: Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags *** You may try to compile using 'make COPTX=-DTRY_EXT2_FS' Again, can you be _specific_? Amusing though your consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. Sending such accusation without knowing the reason is not polite. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: David Woodhouse [EMAIL PROTECTED] wrote: On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote: Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags *** You may try to compile using 'make COPTX=-DTRY_EXT2_FS' Again, can you be _specific_? Amusing though your consistent 'Lunix is broken' chants are, the only reason I'm bothering to participate in this thread is on the off-chance that something _productive_ will come of it. I have been forced to add this test as too many people reported that they have no been able to compile star on their Linux distribution. But do you not know _why_? What exactly are you testing _for_? Bug reports which merely say 'is broken' are not helpful. If you like to know what I test, I encourage you to check the autoconf scripts. I am testing whether the named include file may be used from a user space program. As I did mention already, I was forced to add the test in order to be able to compile at all. By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. Sending such accusation without knowing the reason is not polite. It's not an accusation -- it's merely an observation. You may not have noticed that your mailer was misbehaving; now you _do_ know, and if you care about RFC compliance you might want to fix it. You're not _obliged_ to fix it, of course. I just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: Userspace compiler support of long long
Harald Arnesen [EMAIL PROTECTED] wrote: Adrian Bunk [EMAIL PROTECTED] writes: Is there any userspace Linux compiler that does not support long long? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? TenDRA C: test.c, line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. You cannot use this compiler for any program that uses an interface that needs long long. BTW: C99 requires long long but the Large File summit from 1995 did to the same since 1995. An 32 bit OS that supports large files cannot have a compiler that does not support long long. If TenDRA C does support 64 bit integral type in a different way. TenDRA C would need to deliver include files that take care about this fact. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Sam Ravnborg [EMAIL PROTECTED] wrote:
gcc -c t.c
In file included from /usr/include/linux/ext2_fs.h:20,
from t.c:2:
/usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Hi Jörg.
For my test I used latest -git of the Linux kernel.
In this version the include of ext2_fs_bh.h is guarded
by __KERNEL__ like this:
#ifdef __KERNEL__
#include linux/ext2_fs_sb.h
static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
{
return sb-s_fs_info;
}
Thank you!
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Suse Linux 10.0, I get e.g.: > > > > cat t.c > > #include > > #include > > > > gcc -c t.c > > In file included from /usr/include/linux/ext2_fs.h:20, > > from t.c:2: > > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ > > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before > > âs_next_generationâ > > /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token > > /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token > > Already fixed since kernel 2.6.18. > > Our header were a mess and we are working on getting them better. > But we can't timetravel and fix old distributions. Well, I did report these kind of problems many years ago and as it has not been fixed after some years, I was asuming that it is still the way I see it on Suse 10.0. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Adrian Bunk <[EMAIL PROTECTED]> wrote: > That's a good point I missed. > > What about: > > #if defined(__GNUC__) && __STDC_VERSION__ < 19901L > __extension__ typedef signed long long __s64; > __extension__ typedef unsigned long long __u64; > #else > typedef signed long long __s64; > typedef unsigned long long __u64; > #endif What about using: #if (defined(__GNUC__) || defined(__SUNPRO_C)) && !defined(__STRICT_ANSI__) Well, there seems to be one other compiler (the one from Intel). It may be that if this compiler does not claim to be GCC, another definituion needs to be added. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Adrian Bunk <[EMAIL PROTECTED]> wrote: > > Personally, I think that's a load of bollocks. And it certainly doesn't > > apply to Linux-specific files like , which are perfectly > > entitled to use a C standard from last millennium, regardless of > > namespace 'pollution' issues. That's why we continue to use the crappy > > __u32 types. Can you be more specific about why this is a problem? Don't > > we mostly define those crappy types using arch-specific knowledge, as > > 'int', 'long', etc? > >... > > It would certainly help if Joerg would tell what exactly breaks, but I > spot one likely problem in include/asm-i386/types.h: > > #if defined(__GNUC__) && !defined(__STRICT_ANSI__) > typedef __signed__ long long __s64; > typedef unsigned long long __u64; > #endif > > It might make sense to remove the #if and simply require that > a C compiler under Linux must know about the C99 "long long"? The Sun compiler did support the long long type before gcc did. This is not a problem. I get e.g.: ==> COMPILING "scsihack.o" "/usr/include/linux/byteorder/little_endian.h", line 43: inline keyword applied to __le64: must be a function identifier "/usr/include/linux/byteorder/little_endian.h", line 43: syntax error before or at: __cpu_to_le64p "/usr/include/linux/byteorder/little_endian.h", line 45: operands must have arithmetic type: op "*" "/usr/include/linux/byteorder/little_endian.h", line 47: syntax error before or at: * "/usr/include/linux/byteorder/little_endian.h", line 49: undefined symbol: p "/usr/include/linux/byteorder/little_endian.h", line 49: cannot dereference non-pointer type "/usr/include/linux/byteorder/little_endian.h", line 67: inline keyword applied to __be64: must be a function identifier "/usr/include/linux/byteorder/little_endian.h", line 67: syntax error before or at: __cpu_to_be64p "/usr/include/linux/byteorder/little_endian.h", line 69: syntax error before or at: __swab64p "/usr/include/linux/byteorder/little_endian.h", line 71: syntax error before or at: * "/usr/include/linux/byteorder/little_endian.h", line 73: undefined symbol: p "scsi-linux-sg.c", line 1152: warning: statement not reached cc: acomp failed for scsihack.c And it seems that yout proposal did point into the right direction. After copying /usr/include/linux/types.h to /opt/sunstudio12/prod/include/cc/linux/types.h and removing all #if defined(__GNUC__) && !defined(__STRICT_ANSI__) ... #endif stuff, I got cdrtools compiled using "suncc" and I did even get a woring cdrecord. Thanks for the help! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Harald Arnesen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Joerg Schilling) writes: > > >> If I actually install smake, as Jörg recommends, the message becomes: > >> smake: Can't find any source for 'CCOM_suncc'. > >> smake: Couldn't make 'CCOM_suncc'. > > > > Well, I was in hope that a small typo (in special as the correct spelling > > is in > > the file README.compile) should not be a problem. > > > > You need to use CCOM=suncc > > Then it (star, I haven't tried cdrtools yes) compiles and links fine. > There must be something wrong with your Linux installation. Maybe because it automatically deactivates the Linux extensions if the autoconfiguration sees broken include files. Did you see something like: checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags *** You may try to compile using 'make COPTX=-DTRY_EXT2_FS' Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 25, 2007 at 04:53:55PM +0200, Joerg Schilling wrote:
> >
> > star needs "ext2_fs.h". This file is not usable at all on many Linux
> > distributions, even with GCC.
>
> I was curious so I did:
>
> $ mkdir ~/foo
> $ cd ~/kernel/linux-2.6
> $ make INSTALL_HDR_PATH=~/foo
> $ cd ~/foo
> $ cat j.c
> #include
> #include "etx2_fs.h"
>
> main()
> {
> printf("helloo\n");
> }
>
> $ gcc -o j j.c
> => No warning, no errors
>
On Suse Linux 10.0, I get e.g.:
cat t.c
#include
#include
gcc -c t.c
In file included from /usr/include/linux/ext2_fs.h:20,
from t.c:2:
/usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Sam Ravnborg [EMAIL PROTECTED] wrote:
On Mon, Jun 25, 2007 at 04:53:55PM +0200, Joerg Schilling wrote:
star needs ext2_fs.h. This file is not usable at all on many Linux
distributions, even with GCC.
I was curious so I did:
$ mkdir ~/foo
$ cd ~/kernel/linux-2.6
$ make INSTALL_HDR_PATH=~/foo
$ cd ~/foo
$ cat j.c
#include stdio.h
#include etx2_fs.h
main()
{
printf(helloo\n);
}
$ gcc -o j j.c
= No warning, no errors
On Suse Linux 10.0, I get e.g.:
cat t.c
#include stdio.h
#include linux/ext2_fs.h
gcc -c t.c
In file included from /usr/include/linux/ext2_fs.h:20,
from t.c:2:
/usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
/usr/include/linux/ext2_fs_sb.h:49: error: syntax error before
âs_next_generationâ
/usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
/usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Harald Arnesen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Joerg Schilling) writes: If I actually install smake, as Jörg recommends, the message becomes: smake: Can't find any source for 'CCOM_suncc'. smake: Couldn't make 'CCOM_suncc'. Well, I was in hope that a small typo (in special as the correct spelling is in the file README.compile) should not be a problem. You need to use CCOM=suncc Then it (star, I haven't tried cdrtools yes) compiles and links fine. There must be something wrong with your Linux installation. Maybe because it automatically deactivates the Linux extensions if the autoconfiguration sees broken include files. Did you see something like: checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags *** You may try to compile using 'make COPTX=-DTRY_EXT2_FS' Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Adrian Bunk [EMAIL PROTECTED] wrote: Personally, I think that's a load of bollocks. And it certainly doesn't apply to Linux-specific files like linux/cdrom.h, which are perfectly entitled to use a C standard from last millennium, regardless of namespace 'pollution' issues. That's why we continue to use the crappy __u32 types. Can you be more specific about why this is a problem? Don't we mostly define those crappy types using arch-specific knowledge, as 'int', 'long', etc? ... It would certainly help if Joerg would tell what exactly breaks, but I spot one likely problem in include/asm-i386/types.h: #if defined(__GNUC__) !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif It might make sense to remove the #if and simply require that a C compiler under Linux must know about the C99 long long? The Sun compiler did support the long long type before gcc did. This is not a problem. I get e.g.: == COMPILING scsihack.o /usr/include/linux/byteorder/little_endian.h, line 43: inline keyword applied to __le64: must be a function identifier /usr/include/linux/byteorder/little_endian.h, line 43: syntax error before or at: __cpu_to_le64p /usr/include/linux/byteorder/little_endian.h, line 45: operands must have arithmetic type: op * /usr/include/linux/byteorder/little_endian.h, line 47: syntax error before or at: * /usr/include/linux/byteorder/little_endian.h, line 49: undefined symbol: p /usr/include/linux/byteorder/little_endian.h, line 49: cannot dereference non-pointer type /usr/include/linux/byteorder/little_endian.h, line 67: inline keyword applied to __be64: must be a function identifier /usr/include/linux/byteorder/little_endian.h, line 67: syntax error before or at: __cpu_to_be64p /usr/include/linux/byteorder/little_endian.h, line 69: syntax error before or at: __swab64p /usr/include/linux/byteorder/little_endian.h, line 71: syntax error before or at: * /usr/include/linux/byteorder/little_endian.h, line 73: undefined symbol: p scsi-linux-sg.c, line 1152: warning: statement not reached cc: acomp failed for scsihack.c And it seems that yout proposal did point into the right direction. After copying /usr/include/linux/types.h to /opt/sunstudio12/prod/include/cc/linux/types.h and removing all #if defined(__GNUC__) !defined(__STRICT_ANSI__) ... #endif stuff, I got cdrtools compiled using suncc and I did even get a woring cdrecord. Thanks for the help! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Adrian Bunk [EMAIL PROTECTED] wrote: That's a good point I missed. What about: #if defined(__GNUC__) __STDC_VERSION__ 19901L __extension__ typedef signed long long __s64; __extension__ typedef unsigned long long __u64; #else typedef signed long long __s64; typedef unsigned long long __u64; #endif What about using: #if (defined(__GNUC__) || defined(__SUNPRO_C)) !defined(__STRICT_ANSI__) Well, there seems to be one other compiler (the one from Intel). It may be that if this compiler does not claim to be GCC, another definituion needs to be added. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Adrian Bunk [EMAIL PROTECTED] wrote: On Suse Linux 10.0, I get e.g.: cat t.c #include stdio.h #include linux/ext2_fs.h gcc -c t.c In file included from /usr/include/linux/ext2_fs.h:20, from t.c:2: /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before âs_next_generationâ /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token Already fixed since kernel 2.6.18. Our header were a mess and we are working on getting them better. But we can't timetravel and fix old distributions. Well, I did report these kind of problems many years ago and as it has not been fixed after some years, I was asuming that it is still the way I see it on Suse 10.0. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Harald Arnesen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Joerg Schilling) writes: > > >> FYI, cdrtools also compile and link fine with Sun's C compiler. > > > > M, if you call "cdrecord -scanbus", what do you get? > > I may have misunderstood your make system. I cd-ed into the cdrtools > directory, ran ./Gmake.linux clean (I had already compiled with GCC), > and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of > the make output. > > However, what confused me was that the cdrecord binary wasn't removed. > And scrolling back, I see several compile errors from Sun's C compiler. > > Shouldn't "make clean" remove the executable files? make clean only removes the *.o files. If you call "make relink", all results are removed before recreating. BTW: your problem is caused by a "bash" bug. With a shell that correctly works with "sh -ce 'command...'", you would see an abort after the first error. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Harald Arnesen <[EMAIL PROTECTED]> wrote: > Harald Arnesen <[EMAIL PROTECTED]> writes: > > > [EMAIL PROTECTED] (Joerg Schilling) writes: > > > >>> If I actually install smake, as Jörg recommends, the message becomes: > >>> smake: Can't find any source for 'CCOM_suncc'. > >>> smake: Couldn't make 'CCOM_suncc'. > >> > >> Well, I was in hope that a small typo (in special as the correct spelling > >> is in > >> the file README.compile) should not be a problem. > >> > >> You need to use CCOM=suncc > > > > Then it (star, I haven't tried cdrtools yes) compiles and links fine. > > There must be something wrong with your Linux installation. > > FYI, cdrtools also compile and link fine with Sun's C compiler. M, if you call "cdrecord -scanbus", what do you get? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Harald Arnesen <[EMAIL PROTECTED]> wrote:
> David Woodhouse <[EMAIL PROTECTED]> writes:
>
> >> > Can you be more specific about why this is a problem? Don't
> >> > we mostly define those crappy types using arch-specific knowledge, as
> >> > 'int', 'long', etc?
> >>
> >> I recommend you to install Sun Studio and to try to compile star or
> >> cdrtools
> >> using Sun Studio by calling "make CCOM_suncc".
> >>
> >> ftp://ftp.berlios.de/pub/star/alpha/
> >> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> >>
> >> You may need to hand edit the file incs//{xconfig.h!rules.conf}
> >>
> >> in order to enable the auto-disabled features.
> >>
> >> In any case, self reading the error messages from Sun Studio helps more
> >> than
> >> trying to discuss it.
> >
> > I have no interest in doing this for myself, and I suspect that if I
> > tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
> > anyway. Please just show the error messages.
>
> Apart from the usual whining about GNU make, the error message is:
> make: *** No rule to make target `CCOM_suncc'. Stop.
>
> If I actually install smake, as Jörg recommends, the message becomes:
> smake: Can't find any source for 'CCOM_suncc'.
> smake: Couldn't make 'CCOM_suncc'.
Well, I was in hope that a small typo (in special as the correct spelling is in
the file README.compile) should not be a problem.
You need to use CCOM=suncc
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
> > The main problems are not really hard to fix..
> >
> > - Most problems eem to be related to the fact that Linux does not
> > use C-99 based types in the kernel and the related type definitions
> > are not written in plain C. This is something that should be fixed
> > with a source consolidation program or by defining aliases to
> > C-99 types in case the compiler is not GCC.
>
>
> The argument has been made that the standard C99 types are _optional_,
> and anything included from a C library's headers without _explicitly_
> being included by the user shouldn't define those types.
This uses double negation and is close to unreadable.
A kernel include file that defines an interface to a user space program
should be self containing (that means that all includes for all non-standard
types should be done inside these include files). Whether or not C-99
types are used or not is less important than to use type definitions written
in clean C so compilers other than gcc may use them.
> Personally, I think that's a load of bollocks. And it certainly doesn't
> apply to Linux-specific files like , which are perfectly
> entitled to use a C standard from last millennium, regardless of
> namespace 'pollution' issues. That's why we continue to use the crappy
> __u32 types. Can you be more specific about why this is a problem? Don't
> we mostly define those crappy types using arch-specific knowledge, as
> 'int', 'long', etc?
I recommend you to install Sun Studio and to try to compile star or cdrtools
using Sun Studio by calling "make CCOM_suncc".
ftp://ftp.berlios.de/pub/star/alpha/
ftp://ftp.berlios.de/pub/cdrecord/alpha/
You may need to hand edit the file incs//{xconfig.h!rules.conf}
in order to enable the auto-disabled features.
In any case, self reading the error messages from Sun Studio helps more than
trying to discuss it.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Friday 22 June 2007, [EMAIL PROTECTED] wrote: > > this has been discussed many times and the answer is that the kernel is > > not gong to change it's side of things to ANSI C. > > I don't think that's entirely true with regard to the include files. > We have always tried not to step on anyone's toes there, e.g. regarding > the use of __u32 vs. uint32_t style types. It's certainly desirable > to make the kernel headers that are _meant_ for inclusion compatible > with standard compilers. > > Mike Frysinger has posted a few patches that make the installed headers > friendlier to strict C99 users. While there was some negative feedback > about these patches, it was not about the idea of making the installed > headers C99 clean, but rather about the question whether those non-clean > parts should be exported in the first place. Wouldn't it be simpler to ask the developers to deliver their include files in a state that is clean for user space programs? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > > Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS > > dependent SCSI transport. Cdrtools cannot be compiled wihout support for > > SCSI > > transport, so it is impossible to use Sun Studio to compile cdrtools. > > > > Why does this happen? > > > > Well, the reason is that in order to support Linux specific features, you > > need > > to include Linux specific include files (the Linux kernel include files). > > > I assume you typoed and meant "cleaned up kernel include files as > installed by make headers_install" instead. I am thinking about kernel include files that do correct preincludes for type-cleanness and that work if you use them without #defining __KERNEL_ > > As > > these include files are currently not written in vanilla (ANSI) C but in a > > GCC-C-variant, other compilers do not like these include files. > > can you give a specific example of a header installed by make > headers_install that breaks this way and is hurting you? Because it may > well be possible to fix the problems, now that we have this special > cleanup phase since several releases star needs "ext2_fs.h". This file is not usable at all on many Linux distributions, even with GCC. libscg (cdrtools) needs "scsi/sg.h" but it currently includes a lot of other files: scsi-linux-sg.c:#include scsi-linux-sg.c:#include scsi-linux-sg.c:#include scsi-linux-sg.c:#include scsi-linux-sg.c:#include/* From ancient versions, really needed? */ scsi-linux-sg.c:#include "block/blk.h" /* From ancient versions, really needed? */ scsi-linux-sg.c:#include "scsi/scsi.h" scsi-linux-sg.c:#include "scsi/sg.h" scsi-linux-sg.c:#include If there wase _one_ clean SCSI pass through interface on Linux, things would be a lot easier. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
[EMAIL PROTECTED] wrote: > On Fri, 22 Jun 2007, Joerg Schilling wrote: > > > Is there some hope that at least the Linux kernel interface definition > > files and > > everything recursively included from these files will be rewritten in > > vanilla > > ANSI C? > > this has been discussed many times and the answer is that the kernel is > not gong to change it's side of things to ANSI C. Well, there is no need to go to ANSI C as pre-ANSI would to it also. The problem is non ANSI gcc extensions. > that doesn't mean that one of the many projects out there to create > seperate interface headers won't do this. > > however, there is another interesting thing going on at the moment. The > standards commity is currently deciding what will be in the next rev of > the C specs (tentitivly labels C1x for discussions, they are hopeing to > release them in '09 or '10) > > some of the things that are GCC extentions are going to be added to the > spec (ahtough possibly with a change to the syntax) This may make sense after it did happen, but it does not help today. > so now is the time to talk to your local reps who go to these meetings and > make your suggestions for what should be added to the standard and what > should not be. > > remember that anything to be added must be implemented somehwere, > preferrably by multiple seperate compilers. Using plain C in the Linux kernel include files would be sufficient for all compilers that make sense to be supported. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
[EMAIL PROTECTED] wrote: On Fri, 22 Jun 2007, Joerg Schilling wrote: Is there some hope that at least the Linux kernel interface definition files and everything recursively included from these files will be rewritten in vanilla ANSI C? this has been discussed many times and the answer is that the kernel is not gong to change it's side of things to ANSI C. Well, there is no need to go to ANSI C as pre-ANSI would to it also. The problem is non ANSI gcc extensions. that doesn't mean that one of the many projects out there to create seperate interface headers won't do this. however, there is another interesting thing going on at the moment. The standards commity is currently deciding what will be in the next rev of the C specs (tentitivly labels C1x for discussions, they are hopeing to release them in '09 or '10) some of the things that are GCC extentions are going to be added to the spec (ahtough possibly with a change to the syntax) This may make sense after it did happen, but it does not help today. so now is the time to talk to your local reps who go to these meetings and make your suggestions for what should be added to the standard and what should not be. remember that anything to be added must be implemented somehwere, preferrably by multiple seperate compilers. Using plain C in the Linux kernel include files would be sufficient for all compilers that make sense to be supported. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Arjan van de Ven [EMAIL PROTECTED] wrote: Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI transport, so it is impossible to use Sun Studio to compile cdrtools. Why does this happen? Well, the reason is that in order to support Linux specific features, you need to include Linux specific include files (the Linux kernel include files). I assume you typoed and meant cleaned up kernel include files as installed by make headers_install instead. I am thinking about kernel include files that do correct preincludes for type-cleanness and that work if you use them without #defining __KERNEL_ As these include files are currently not written in vanilla (ANSI) C but in a GCC-C-variant, other compilers do not like these include files. can you give a specific example of a header installed by make headers_install that breaks this way and is hurting you? Because it may well be possible to fix the problems, now that we have this special cleanup phase since several releases star needs ext2_fs.h. This file is not usable at all on many Linux distributions, even with GCC. libscg (cdrtools) needs scsi/sg.h but it currently includes a lot of other files: scsi-linux-sg.c:#include linux/version.h scsi-linux-sg.c:#include asm/types.h scsi-linux-sg.c:#include scsi/scsi.h scsi-linux-sg.c:#include linux/scsi.h scsi-linux-sg.c:#include linux/fs.h /* From ancient versions, really needed? */ scsi-linux-sg.c:#include block/blk.h /* From ancient versions, really needed? */ scsi-linux-sg.c:#include scsi/scsi.h scsi-linux-sg.c:#include scsi/sg.h scsi-linux-sg.c:#include linux/cdrom.h If there wase _one_ clean SCSI pass through interface on Linux, things would be a lot easier. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Arnd Bergmann [EMAIL PROTECTED] wrote: On Friday 22 June 2007, [EMAIL PROTECTED] wrote: this has been discussed many times and the answer is that the kernel is not gong to change it's side of things to ANSI C. I don't think that's entirely true with regard to the include files. We have always tried not to step on anyone's toes there, e.g. regarding the use of __u32 vs. uint32_t style types. It's certainly desirable to make the kernel headers that are _meant_ for inclusion compatible with standard compilers. Mike Frysinger has posted a few patches that make the installed headers friendlier to strict C99 users. While there was some negative feedback about these patches, it was not about the idea of making the installed headers C99 clean, but rather about the question whether those non-clean parts should be exported in the first place. Wouldn't it be simpler to ask the developers to deliver their include files in a state that is clean for user space programs? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
David Woodhouse [EMAIL PROTECTED] wrote:
On Fri, 2007-06-22 at 01:38 +0200, Joerg Schilling wrote:
The main problems are not really hard to fix..
- Most problems eem to be related to the fact that Linux does not
use C-99 based types in the kernel and the related type definitions
are not written in plain C. This is something that should be fixed
with a source consolidation program or by defining aliases to
C-99 types in case the compiler is not GCC.
The argument has been made that the standard C99 types are _optional_,
and anything included from a C library's headers without _explicitly_
being included by the user shouldn't define those types.
This uses double negation and is close to unreadable.
A kernel include file that defines an interface to a user space program
should be self containing (that means that all includes for all non-standard
types should be done inside these include files). Whether or not C-99
types are used or not is less important than to use type definitions written
in clean C so compilers other than gcc may use them.
Personally, I think that's a load of bollocks. And it certainly doesn't
apply to Linux-specific files like linux/cdrom.h, which are perfectly
entitled to use a C standard from last millennium, regardless of
namespace 'pollution' issues. That's why we continue to use the crappy
__u32 types. Can you be more specific about why this is a problem? Don't
we mostly define those crappy types using arch-specific knowledge, as
'int', 'long', etc?
I recommend you to install Sun Studio and to try to compile star or cdrtools
using Sun Studio by calling make CCOM_suncc.
ftp://ftp.berlios.de/pub/star/alpha/
ftp://ftp.berlios.de/pub/cdrecord/alpha/
You may need to hand edit the file incs/arch-dir/{xconfig.h!rules.conf}
in order to enable the auto-disabled features.
In any case, self reading the error messages from Sun Studio helps more than
trying to discuss it.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Harald Arnesen [EMAIL PROTECTED] wrote:
David Woodhouse [EMAIL PROTECTED] writes:
Can you be more specific about why this is a problem? Don't
we mostly define those crappy types using arch-specific knowledge, as
'int', 'long', etc?
I recommend you to install Sun Studio and to try to compile star or
cdrtools
using Sun Studio by calling make CCOM_suncc.
ftp://ftp.berlios.de/pub/star/alpha/
ftp://ftp.berlios.de/pub/cdrecord/alpha/
You may need to hand edit the file incs/arch-dir/{xconfig.h!rules.conf}
in order to enable the auto-disabled features.
In any case, self reading the error messages from Sun Studio helps more
than
trying to discuss it.
I have no interest in doing this for myself, and I suspect that if I
tried it I'd find that Sun Studio doesn't exist for Linux/PowerPC
anyway. Please just show the error messages.
Apart from the usual whining about GNU make, the error message is:
make: *** No rule to make target `CCOM_suncc'. Stop.
If I actually install smake, as Jörg recommends, the message becomes:
smake: Can't find any source for 'CCOM_suncc'.
smake: Couldn't make 'CCOM_suncc'.
Well, I was in hope that a small typo (in special as the correct spelling is in
the file README.compile) should not be a problem.
You need to use CCOM=suncc
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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 include files
Harald Arnesen [EMAIL PROTECTED] wrote: Harald Arnesen [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Joerg Schilling) writes: If I actually install smake, as Jörg recommends, the message becomes: smake: Can't find any source for 'CCOM_suncc'. smake: Couldn't make 'CCOM_suncc'. Well, I was in hope that a small typo (in special as the correct spelling is in the file README.compile) should not be a problem. You need to use CCOM=suncc Then it (star, I haven't tried cdrtools yes) compiles and links fine. There must be something wrong with your Linux installation. FYI, cdrtools also compile and link fine with Sun's C compiler. M, if you call cdrecord -scanbus, what do you get? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
Harald Arnesen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Joerg Schilling) writes: FYI, cdrtools also compile and link fine with Sun's C compiler. M, if you call cdrecord -scanbus, what do you get? I may have misunderstood your make system. I cd-ed into the cdrtools directory, ran ./Gmake.linux clean (I had already compiled with GCC), and then ./Gmake.linux CCOM=suncc. I didn't see any errors at the end of the make output. However, what confused me was that the cdrecord binary wasn't removed. And scrolling back, I see several compile errors from Sun's C compiler. Shouldn't make clean remove the executable files? make clean only removes the *.o files. If you call make relink, all results are removed before recreating. BTW: your problem is caused by a bash bug. With a shell that correctly works with sh -ce 'command...', you would see an abort after the first error. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
[EMAIL PROTECTED] wrote: > On Fri, 22 Jun 2007, Joerg Schilling wrote: > > > Is there some hope that at least the Linux kernel interface definition > > files and > > everything recursively included from these files will be rewritten in > > vanilla > > ANSI C? > > this has been discussed many times and the answer is that the kernel is > not gong to change it's side of things to ANSI C. > > that doesn't mean that one of the many projects out there to create > seperate interface headers won't do this. The main problems are not really hard to fix.. - Most problems eem to be related to the fact that Linux does not use C-99 based types in the kernel and the related type definitions are not written in plain C. This is something that should be fixed with a source consolidation program or by defining aliases to C-99 types in case the compiler is not GCC. - Other problems are caused by additional tag definitions that could be disabled in case of a non-GCC compile. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
Linux Kernel include files
Hi all, you might know that since ~ 2 years, the Sun Studio compilers are available for Linux. Given the fact that they typically produce faster code than GCC and that they offer more debug/optimizing features, they are worth testing. While it is no problem to use Sun Studio for non-Linux-specific programs, it is impossible to compile programs using Sun Studio if these programs offer Linux specific features. Star ftp://ftp.berlios.de/pub/star/alpha/ offers support for archiving ext2 file flags. If star is compiled using Sun Studio, star's autoconfiguration will disable support for the Linux specific features because it detects "broken" include files. Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI transport, so it is impossible to use Sun Studio to compile cdrtools. Why does this happen? Well, the reason is that in order to support Linux specific features, you need to include Linux specific include files (the Linux kernel include files). As these include files are currently not written in vanilla (ANSI) C but in a GCC-C-variant, other compilers do not like these include files. Is there some hope that at least the Linux kernel interface definition files and everything recursively included from these files will be rewritten in vanilla ANSI C? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
Linux Kernel include files
Hi all, you might know that since ~ 2 years, the Sun Studio compilers are available for Linux. Given the fact that they typically produce faster code than GCC and that they offer more debug/optimizing features, they are worth testing. While it is no problem to use Sun Studio for non-Linux-specific programs, it is impossible to compile programs using Sun Studio if these programs offer Linux specific features. Star ftp://ftp.berlios.de/pub/star/alpha/ offers support for archiving ext2 file flags. If star is compiled using Sun Studio, star's autoconfiguration will disable support for the Linux specific features because it detects broken include files. Cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ offer support for an OS dependent SCSI transport. Cdrtools cannot be compiled wihout support for SCSI transport, so it is impossible to use Sun Studio to compile cdrtools. Why does this happen? Well, the reason is that in order to support Linux specific features, you need to include Linux specific include files (the Linux kernel include files). As these include files are currently not written in vanilla (ANSI) C but in a GCC-C-variant, other compilers do not like these include files. Is there some hope that at least the Linux kernel interface definition files and everything recursively included from these files will be rewritten in vanilla ANSI C? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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 include files
[EMAIL PROTECTED] wrote: On Fri, 22 Jun 2007, Joerg Schilling wrote: Is there some hope that at least the Linux kernel interface definition files and everything recursively included from these files will be rewritten in vanilla ANSI C? this has been discussed many times and the answer is that the kernel is not gong to change it's side of things to ANSI C. that doesn't mean that one of the many projects out there to create seperate interface headers won't do this. The main problems are not really hard to fix.. - Most problems eem to be related to the fact that Linux does not use C-99 based types in the kernel and the related type definitions are not written in plain C. This is something that should be fixed with a source consolidation program or by defining aliases to C-99 types in case the compiler is not GCC. - Other problems are caused by additional tag definitions that could be disabled in case of a non-GCC compile. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Any chance to that this bug will be fixed anytime soon?
The Bug has been reported February 2004 but is still not fixed in sg.c
Is Linux development really so slow?
Douglas Gilbert <[EMAIL PROTECTED]> wrote:
> Alan,
> The SG_GET_RESERVED_SIZE ioctl is also defined in
> the block layer, see block/scsi_ioctl.c .
> I suspect it is just a kludge to fool cdrecord that it
> is talking to a sg device. [One of many kludges in the
> block SG_IO ioctl implementation to that end.]
> So perhaps the block layer versions of SG_SET_RESERVED_SIZE
> and SG_GET_RESERVED_SIZE need to be similarly capped.
> Actually I think that I would default SG_GET_RESERVED_SIZE to
> request_queue->max_sectors * 512 in the block layer
> implementation (as there is no "reserve buffer" associated
> with a block device).
>
>
>
> The idea of a reserved buffer may live on in bsg as experience
> with sg has shown that it is the fastest way to do (mmap-ed) IO.
> Having one reserved buffer per file descriptor means not
> having to create and tear down a scatter gather list
> per IO. [Having a pool of such lists would be even better.]
> Until optical storage needs 10 times its current datarates
> then cdrecord will not need this mechanism.
>
>
> Doug Gilbert
>
>
> > Index: usb-2.6/drivers/scsi/sg.c
> > ===
> > --- usb-2.6.orig/drivers/scsi/sg.c
> > +++ usb-2.6/drivers/scsi/sg.c
> > @@ -917,6 +917,8 @@ sg_ioctl(struct inode *inode, struct fil
> > return result;
> > if (val < 0)
> > return -EINVAL;
> > + if (val > sdp->device->request_queue->max_sectors * 512)
> > + return -EOVERFLOW;
> > if (val != sfp->reserve.bufflen) {
> > if (sg_res_in_use(sfp) || sfp->mmap_called)
> > return -EBUSY;
> > @@ -925,7 +927,8 @@ sg_ioctl(struct inode *inode, struct fil
> > }
> > return 0;
> > case SG_GET_RESERVED_SIZE:
> > - val = (int) sfp->reserve.bufflen;
> > + val = min_t(int, sfp->reserve.bufflen,
> > + sdp->device->request_queue->max_sectors * 512);
> > return put_user(val, ip);
> > case SG_SET_COMMAND_Q:
> > result = get_user(val, ip);
> >
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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] Block layer: separate out queue-oriented ioctls
Any chance to that this bug will be fixed anytime soon?
The Bug has been reported February 2004 but is still not fixed in sg.c
Is Linux development really so slow?
Douglas Gilbert [EMAIL PROTECTED] wrote:
Alan,
The SG_GET_RESERVED_SIZE ioctl is also defined in
the block layer, see block/scsi_ioctl.c .
I suspect it is just a kludge to fool cdrecord that it
is talking to a sg device. [One of many kludges in the
block SG_IO ioctl implementation to that end.]
So perhaps the block layer versions of SG_SET_RESERVED_SIZE
and SG_GET_RESERVED_SIZE need to be similarly capped.
Actually I think that I would default SG_GET_RESERVED_SIZE to
request_queue-max_sectors * 512 in the block layer
implementation (as there is no reserve buffer associated
with a block device).
aside
The idea of a reserved buffer may live on in bsg as experience
with sg has shown that it is the fastest way to do (mmap-ed) IO.
Having one reserved buffer per file descriptor means not
having to create and tear down a scatter gather list
per IO. [Having a pool of such lists would be even better.]
Until optical storage needs 10 times its current datarates
then cdrecord will not need this mechanism.
/aside
Doug Gilbert
Index: usb-2.6/drivers/scsi/sg.c
===
--- usb-2.6.orig/drivers/scsi/sg.c
+++ usb-2.6/drivers/scsi/sg.c
@@ -917,6 +917,8 @@ sg_ioctl(struct inode *inode, struct fil
return result;
if (val 0)
return -EINVAL;
+ if (val sdp-device-request_queue-max_sectors * 512)
+ return -EOVERFLOW;
if (val != sfp-reserve.bufflen) {
if (sg_res_in_use(sfp) || sfp-mmap_called)
return -EBUSY;
@@ -925,7 +927,8 @@ sg_ioctl(struct inode *inode, struct fil
}
return 0;
case SG_GET_RESERVED_SIZE:
- val = (int) sfp-reserve.bufflen;
+ val = min_t(int, sfp-reserve.bufflen,
+ sdp-device-request_queue-max_sectors * 512);
return put_user(val, ip);
case SG_SET_COMMAND_Q:
result = get_user(val, ip);
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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] Block layer: separate out queue-oriented ioctls Re: [PATCH] Block layer: separate out queue-oriented ioctls
Hi, this is a repost as I like to know the current state of the problem... The USB DMA size problem is known to exist on Linux since February 2004. I am still in hope that there will be a fix soon. /*--*/ Alan Stern <[EMAIL PROTECTED]> wrote: > Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE, > it's okay with me. An advantage of doing this is that older versions of > cdrecord would then work correctly. > > However you don't seem to realize that people can use programs like > cdrecord with devices whose drivers don't support SG_GET_RESERVED_SIZE -- > because that ioctl works only with sg. Programs would have to try > SG_GET_RESERVED_SIZE and if it faied, then try BLKSECTGET. Is there any reason not to have one single ioctl for one basic feature? > Remember also, the "reserved size" is _not_ the maximum allowed size of a > DMA transfer. Rather, it is the size of an internal buffer maintained by > sg. It's legal to do an I/O transfer larger than the "reserved size", but > it is not legal to do an I/O transfer larger than max_sectors. At the time the call SG_GET_RESERVED_SIZE has been discussed/defined, we did originally agree that the max value should be limited to what the HW allows as DMA size. This is why I did originally files a bug against SG_GET_RESERVED_SIZE. /*--*/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls Re: [PATCH] Block layer: separate out queue-oriented ioctls
Hi, this is a repost as I like to know the current state of the problem... The USB DMA size problem is known to exist on Linux since February 2004. I am still in hope that there will be a fix soon. /*--*/ Alan Stern [EMAIL PROTECTED] wrote: Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE, it's okay with me. An advantage of doing this is that older versions of cdrecord would then work correctly. However you don't seem to realize that people can use programs like cdrecord with devices whose drivers don't support SG_GET_RESERVED_SIZE -- because that ioctl works only with sg. Programs would have to try SG_GET_RESERVED_SIZE and if it faied, then try BLKSECTGET. Is there any reason not to have one single ioctl for one basic feature? Remember also, the reserved size is _not_ the maximum allowed size of a DMA transfer. Rather, it is the size of an internal buffer maintained by sg. It's legal to do an I/O transfer larger than the reserved size, but it is not legal to do an I/O transfer larger than max_sectors. At the time the call SG_GET_RESERVED_SIZE has been discussed/defined, we did originally agree that the max value should be limited to what the HW allows as DMA size. This is why I did originally files a bug against SG_GET_RESERVED_SIZE. /*--*/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Alan Stern <[EMAIL PROTECTED]> wrote: > Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE, > it's okay with me. An advantage of doing this is that older versions of > cdrecord would then work correctly. > > However you don't seem to realize that people can use programs like > cdrecord with devices whose drivers don't support SG_GET_RESERVED_SIZE -- > because that ioctl works only with sg. Programs would have to try > SG_GET_RESERVED_SIZE and if it faied, then try BLKSECTGET. Is there any reason not to have one single ioctl for one basic feature? > Remember also, the "reserved size" is _not_ the maximum allowed size of a > DMA transfer. Rather, it is the size of an internal buffer maintained by > sg. It's legal to do an I/O transfer larger than the "reserved size", but > it is not legal to do an I/O transfer larger than max_sectors. At the time the call SG_GET_RESERVED_SIZE has been discussed/defined, we did originally agree that the max value should be limited to what the HW allows as DMA size. This is why I did originally files a bug against SG_GET_RESERVED_SIZE. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Alan Stern [EMAIL PROTECTED] wrote: Well, if Doug wants to reduce the value returned by SG_GET_RESERVED_SIZE, it's okay with me. An advantage of doing this is that older versions of cdrecord would then work correctly. However you don't seem to realize that people can use programs like cdrecord with devices whose drivers don't support SG_GET_RESERVED_SIZE -- because that ioctl works only with sg. Programs would have to try SG_GET_RESERVED_SIZE and if it faied, then try BLKSECTGET. Is there any reason not to have one single ioctl for one basic feature? Remember also, the reserved size is _not_ the maximum allowed size of a DMA transfer. Rather, it is the size of an internal buffer maintained by sg. It's legal to do an I/O transfer larger than the reserved size, but it is not legal to do an I/O transfer larger than max_sectors. At the time the call SG_GET_RESERVED_SIZE has been discussed/defined, we did originally agree that the max value should be limited to what the HW allows as DMA size. This is why I did originally files a bug against SG_GET_RESERVED_SIZE. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Alan Stern <[EMAIL PROTECTED]> wrote: > > Alternatively the SG_GET_RESERVED_SIZE ioctl could be > > modified to yield no more than max_sectors*512 . > > There should be one single ioctl which can be applied uniformly to all > CD-type devices (in fact, to all devices using a request_queue) to learn > max_sectors. This rules out using SG_GET_RESERVED_SIZE. This has nothing to do with CD-type devices! It is related to SCSI tansport. > Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would > only increase the confusion. The reserved size isn't directly related to > the maximum allowed DMA length, and there's no point pretending it is. > What if it turns out that the reserved size is smaller than max_sectors? > Then you'd force user programs to do I/O in chunks that were smaller than > necessary. It would not increase confusion but reduce confusion because all programs would later behave correctly without the need to change them. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Douglas Gilbert <[EMAIL PROTECTED]> wrote: > Jens Axboe wrote: > > On Fri, Feb 16 2007, Alan Stern wrote: > >> From: James Bottomley <[EMAIL PROTECTED]> > >> > >> This patch (as854) separates out the two queue-oriented ioctls from > >> the rest of the block-layer ioctls. The idea is that they should > >> apply to any driver using a request_queue, even if the driver doesn't > >> implement a block-device interface. The prototypical example is the > >> sg driver, to which the patch adds the new interface. > >> > >> This will make it possible for cdrecord and related programs to > >> retrieve reliably the max_sectors value, regardless of whether the > >> user points it to an sr or an sg device. In particular, this will > >> resolve Bugzilla entry #7026. > > > > The block bits are fine with me, the sg calling point is a bit of a sore > > thumb (a char driver calling into block layer ioctls) though. So the > > block layer bits are certainly ok with me, if Doug acks the sg bit I'll > > merge everything up. > > > > (patch left below) > > Does this need to be in the sg driver? > > What is the hardware sector size of a SES or OSD device? > > As for the max_sector variable, wouldn't it be better > to generate a new ioctl that yielded the limit in bytes? > Making a driver variable that implicitly assumes sectors > are 512 bytes in length more visible to the user space > seems like a step in the wrong direction. This is what I did propose. I know of no SCSI device made since 1986 that has a "hardware sector size". This is really a DMA size limit in bytes and if you return the number in an unrelated multiple of a fraction, you will not be able to use the optmium max transfer size. > Alternatively the SG_GET_RESERVED_SIZE ioctl could be > modified to yield no more than max_sectors*512 . This is what I did propose 3 months ago and already 2 years ago. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Douglas Gilbert [EMAIL PROTECTED] wrote: Jens Axboe wrote: On Fri, Feb 16 2007, Alan Stern wrote: From: James Bottomley [EMAIL PROTECTED] This patch (as854) separates out the two queue-oriented ioctls from the rest of the block-layer ioctls. The idea is that they should apply to any driver using a request_queue, even if the driver doesn't implement a block-device interface. The prototypical example is the sg driver, to which the patch adds the new interface. This will make it possible for cdrecord and related programs to retrieve reliably the max_sectors value, regardless of whether the user points it to an sr or an sg device. In particular, this will resolve Bugzilla entry #7026. The block bits are fine with me, the sg calling point is a bit of a sore thumb (a char driver calling into block layer ioctls) though. So the block layer bits are certainly ok with me, if Doug acks the sg bit I'll merge everything up. (patch left below) Does this need to be in the sg driver? What is the hardware sector size of a SES or OSD device? As for the max_sector variable, wouldn't it be better to generate a new ioctl that yielded the limit in bytes? Making a driver variable that implicitly assumes sectors are 512 bytes in length more visible to the user space seems like a step in the wrong direction. This is what I did propose. I know of no SCSI device made since 1986 that has a hardware sector size. This is really a DMA size limit in bytes and if you return the number in an unrelated multiple of a fraction, you will not be able to use the optmium max transfer size. Alternatively the SG_GET_RESERVED_SIZE ioctl could be modified to yield no more than max_sectors*512 . This is what I did propose 3 months ago and already 2 years ago. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Alan Stern [EMAIL PROTECTED] wrote: Alternatively the SG_GET_RESERVED_SIZE ioctl could be modified to yield no more than max_sectors*512 . There should be one single ioctl which can be applied uniformly to all CD-type devices (in fact, to all devices using a request_queue) to learn max_sectors. This rules out using SG_GET_RESERVED_SIZE. This has nothing to do with CD-type devices! It is related to SCSI tansport. Furthermore, if you changed SG_GET_RESERVED_SIZE in this way you would only increase the confusion. The reserved size isn't directly related to the maximum allowed DMA length, and there's no point pretending it is. What if it turns out that the reserved size is smaller than max_sectors? Then you'd force user programs to do I/O in chunks that were smaller than necessary. It would not increase confusion but reduce confusion because all programs would later behave correctly without the need to change them. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Jens Axboe <[EMAIL PROTECTED]> wrote: > > This will make it possible for cdrecord and related programs to > > retrieve reliably the max_sectors value, regardless of whether the > > user points it to an sr or an sg device. In particular, this will > > resolve Bugzilla entry #7026. > > The block bits are fine with me, the sg calling point is a bit of a sore > thumb (a char driver calling into block layer ioctls) though. So the > block layer bits are certainly ok with me, if Doug acks the sg bit I'll > merge everything up. If you care about this kind of order, you would first need to eliminate the ability of doing low level things like SG_IO from block drivers as this is similar low level stuff that rather belongs to low level drivers. Any driver that allows to use low level interfaces to send RAW SCSI commands also needs access to other lowlevel stuff like the ability to know the max. DMA size. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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] Block layer: separate out queue-oriented ioctls
Jens Axboe [EMAIL PROTECTED] wrote: This will make it possible for cdrecord and related programs to retrieve reliably the max_sectors value, regardless of whether the user points it to an sr or an sg device. In particular, this will resolve Bugzilla entry #7026. The block bits are fine with me, the sg calling point is a bit of a sore thumb (a char driver calling into block layer ioctls) though. So the block layer bits are certainly ok with me, if Doug acks the sg bit I'll merge everything up. If you care about this kind of order, you would first need to eliminate the ability of doing low level things like SG_IO from block drivers as this is similar low level stuff that rather belongs to low level drivers. Any driver that allows to use low level interfaces to send RAW SCSI commands also needs access to other lowlevel stuff like the ability to know the max. DMA size. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: 2.6.19 kernel series, SATA, wodim (cd recording), synaptics update,
Jens Axboe <[EMAIL PROTECTED]> wrote: > On Thu, Dec 14 2006, Joerg Schilling wrote: > > >CD recording : recorder no longer detected by "wodim" software set in > > >2.6.19. I suspect it's a bug in the software... but don't know where > > >to look for changes. 2.6.19-rc5 worked. > > >hardware: IDE MATSHITADVD-RAM UJ-820S > > >(2.6.19-git6 also fails with external LiteON USB DVD burner) > > It was an intermittent unlucky bug between 2.6.19 and 2.6.20-rc1, it got > fixed the other day. Update your kernel, and it'll work again. OK, thank you for the info. > > Do not use cdrecord derivates but the original as derivates may have bugs > > that are not present in the original. > > And vice versa :-) I know of no problem that is only in the original, but there are dozens of problems that have been fixed since the derivate has been frozen in May. If you know of any problem in the original, feel fre to report it! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: 2.6.19 kernel series, SATA, wodim (cd recording), synaptics update,
>CD recording : recorder no longer detected by "wodim" software set in >2.6.19. I suspect it's a bug in the software... but don't know where >to look for changes. 2.6.19-rc5 worked. >hardware: IDE MATSHITADVD-RAM UJ-820S >(2.6.19-git6 also fails with external LiteON USB DVD burner) I recommend to check the latest cdrtools packet from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ At the same place, there is a patch for recent Linux systems that allows cdrecord to sense the MAX DMA size for USB. Do not use cdrecord derivates but the original as derivates may have bugs that are not present in the original. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: 2.6.19 kernel series, SATA, wodim (cd recording), synaptics update,
CD recording : recorder no longer detected by wodim software set in 2.6.19. I suspect it's a bug in the software... but don't know where to look for changes. 2.6.19-rc5 worked. hardware: IDE MATSHITADVD-RAM UJ-820S (2.6.19-git6 also fails with external LiteON USB DVD burner) I recommend to check the latest cdrtools packet from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ At the same place, there is a patch for recent Linux systems that allows cdrecord to sense the MAX DMA size for USB. Do not use cdrecord derivates but the original as derivates may have bugs that are not present in the original. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: 2.6.19 kernel series, SATA, wodim (cd recording), synaptics update,
Jens Axboe [EMAIL PROTECTED] wrote: On Thu, Dec 14 2006, Joerg Schilling wrote: CD recording : recorder no longer detected by wodim software set in 2.6.19. I suspect it's a bug in the software... but don't know where to look for changes. 2.6.19-rc5 worked. hardware: IDE MATSHITADVD-RAM UJ-820S (2.6.19-git6 also fails with external LiteON USB DVD burner) It was an intermittent unlucky bug between 2.6.19 and 2.6.20-rc1, it got fixed the other day. Update your kernel, and it'll work again. OK, thank you for the info. Do not use cdrecord derivates but the original as derivates may have bugs that are not present in the original. And vice versa :-) I know of no problem that is only in the original, but there are dozens of problems that have been fixed since the derivate has been frozen in May. If you know of any problem in the original, feel fre to report it! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
>From [EMAIL PROTECTED] Tue Oct 17 01:14:32 2000 >1.8.1. A ricoh 9060 on a machine running identical kernel build / >cdrecord binary works fine> >I just finished compiling cdrecord-1.8.1 with debug enabled. The two >attached log files are from the hp7100i / smp / 2.2.18pre15, and the >ricoh 9060 / up /2.2.18pre15. Exact same cdrw media. ># ./cdrecord -debug dev=1,0,0 blank=all 2>&1 | tee log.(hp7100|ricoh) Without a usable error report, I cannot help... Read: http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html Your cdrecord is old, -debug is useless to find what happens, your log does not contain all output of cdrecord. However it may be a broken hp7100: I suspect that all drives ever made are now dead because of bad quality. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
