Re: How can I add a function to the kernel initialization
These things usually sit off a serial port.
I.E. /dev/lcd is a link to /dev/ttyS0 or whatever.
Anyway the main point is you don't have access to libc.
So how can you access the serial port from the booting
kernel. Well to spit kernel messages out the serial
port you pass the console=ttyS1,19200 or equivalent
parameter to the kernel. So see what that is done
in the kernel code and copy.
Note www.kernelnewbies.org is probably more appropriate
for this sort of question.
Padraig.
Bart Trojanowski wrote:
>
> First it does not work because you do not have access to libc in the
> kernel. Secondly your LCD driver is not available at the time of
> start_kernel so there is no one to listen to the /dev/lcd.
>
> The quickest hack would be to find your lcd driver and modify it to spit
> out the Loading Kernel, after it initializes.
>
> B.
>
> On Wed, 11 Apr 2001, [EMAIL PROTECTED] wrote:
>
> > I have written a driver for a character set LCD module using parallel port. I want
>to display a message when the kernel is initialized.
> >
> > I added the following to start_kernel() in init/main.c
> >
> > #include
> >
> > {
> > int i;
> > char line = "Loading Kernel";
> > FILE *ptr;
> > ptr = fopen("/dev/lcd","w");
> >
> > for (i=0;i<10;i++)
> > {
> > fprintf(ptr, "%s\n", line);
> > }
> > fclose(ptr);
> > }
> >
> > Error was found, it looks like that it can not include stdio.h in the
>initialization.
> > How can I do that?
> >
> > I wish to be personally CC'ed the answers/comments posted to the list in response
>to my posting. Thank you.
> >
> > Best Regards,
> > Anton
-
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: gzipped executables
You might consider UPX (http://upx.tsx.org) Very cool. The beta version supports compressing the kernel and "direct-to-memory" compression. I think it still has the disadvantage of not sharing segments between many instances of the same program. Is there any way of fixing this? (probably would have to hack a bit with the loader?) For a general solution I would look @ changing the filesystem so that particular files (not just executables) can be compressed/ decompressed transparently. (I.E. for ext2 implement `chattr +c`). Padraig. Ingo Oeser wrote: > On Tue, Feb 13, 2001 at 08:40:31AM -, [EMAIL PROTECTED] wrote: > >> On Mon, 12 Feb 2001 23:09:39 -0600 (CST) Matt Stegman <[EMAIL PROTECTED]> wrote: >> >>> Is there any kernel patch that would allow Linux to properly recognize, >>> and execute gzipped executables? >> >> Perhaps you could put it in the filesystem. Look at the >> "chattr" manpage, which shows how this is meant to work with >> ext2. It seems not to have been implemented yet. This way you >> could also compress any files, not just executables. > > > A nice way already implemented in 2.4.x is cramfs. Many embedded > people (like me) use it to fill up their flash disks. > > Look at linux/Documentation/filesystems/cramfs.txt for more info. > > Regards > > Ingo Oeser - 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: [OFFTOPIC] Hardlink utility - reclaim drive space
Hmm.. useful until you actually want to modify a linked file, but then your modifying the file in all "merged" trees. Wouldn't it be cool to have an extended attribute for files called "Copy on Write", so then you could hardlink all duplicate files together, but when a file is modified a copy is transparently created. Actually should it be called "Copy On Modify"? since if you copied a file there would be no need to make an actual copy until the file was modified. The only problem I see with this is that you wouldn't have enough space to store a copy of a file, what would you do in this case, just return an error on write? Is there any way this could be extended across filesystems? I suppose you could add it on top of existing DFS'? I could see many uses for this, like backup systems, but perhaps a block level system is more appropriate in this case? (like the just announced SnapFS). Is there any filesystem that supports this @ present? Padraig. William Stearns wrote: > Good day, all, > Sorry for the offtopic post; I sincerely believe this will be > useful to developers with multiple copies of, say, the linux kernel tree > on their drives. I'll be brief. Please followup to private mail - > thanks. > Freedups scans the directories you give it for identical files and > hardlinks them together to save drive space. Please see > ftp://ftp.stearns.org/pub/freedups . V0.2.1 is up there; it has received > some testing, but may yet contain bugs. > I was able to recover ~676M by running it against 8 different > 2.4.x kernel trees with different patches that originally contained ~948M > of files. YMMV. > I do understand there are better ways to handle this problem (cp > -av --link, cvs? Bitkeeper, deleting unneeded trees, tarring up trees, > etc.). See the readme for a little discussion on this. This is just one > approach that may be useful in some situations. > Cheers, > - Bill - 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: [OFFTOPIC] Hardlink utility - reclaim drive space
Jeremy Jackson wrote: > Padraig Brady wrote: > >> Hmm.. useful until you actually want to modify a linked file, >> but then your modifying the file in all "merged" trees. >> Wouldn't it be cool to have an extended attribute >> for files called "Copy on Write", so then you could >> hardlink all duplicate files together, but when a file is >> modified a copy is transparently created. >> Actually should it be called "Copy On Modify"? since if >> you copied a file there would be no need to make an actual >> copy until the file was modified. >> >> The only problem I see with this is that you wouldn't have >> enough space to store a copy of a file, what would you do >> in this case, just return an error on write? >> >> Is there any way this could be extended across filesystems? >> I suppose you could add it on top of existing DFS'? >> >> I could see many uses for this, like backup systems, but perhaps >> a block level system is more appropriate in this case? >> (like the just announced SnapFS). >> >> Is there any filesystem that supports this @ present? >> >> Padraig. >> >> William Stearns wrote: >> >>> Good day, all, >>> Sorry for the offtopic post; I sincerely believe this will be >>> useful to developers with multiple copies of, say, the linux kernel tree >>> on their drives. I'll be brief. Please followup to private mail - >>> thanks. >>> Freedups scans the directories you give it for identical files and >>> hardlinks them together to save drive space. Please see >>> ftp://ftp.stearns.org/pub/freedups . V0.2.1 is up there; it has received >>> some testing, but may yet contain bugs. >>> I was able to recover ~676M by running it against 8 different >>> 2.4.x kernel trees with different patches that originally contained ~948M >>> of files. YMMV. >>> I do understand there are better ways to handle this problem (cp >>> -av --link, cvs? Bitkeeper, deleting unneeded trees, tarring up trees, >>> etc.). See the readme for a little discussion on this. This is just one >>> approach that may be useful in some situations. >>> Cheers, >>> - Bill >> > snapFS might handle this - versioning, copy-on-write disk file > clones... even finer grained: only modified blocks of a file are > duplicated, not the entire file, and it does this in real-time. Yes I mentioned snapFS above, and a block level system would be a win for large files, that are quite similar. However in my experience this is usually not the case, i.e. large files are usually not similar, so a simple file level system would be more appropriate im my opinion. Also I don't think user space progs should be relied on to manage hardlinked files by (effectively) doing: cp orig temp; mv temp orig You could use file permissions (chmod -w orig) to remind you to do this, but that's just a kludge, and also it's messy with every user space prog doing something different. Also the cp above breaks the link, which you wouldn't want to do until the file is actually modified. So if you implemented the "Copy On modify" extended attribute, you could set cp to cp -l by default. I'm talking about something more general here than working with a few similar trees. This is a general way to never have duplicate files on a filesystem. Doing this at the block level would be more fine grained, but at the cost of much more complexity and processing time, especially if you want to analyse an existing filesystem. If you do it @ the file level, you can just scan for duplicate files, merge them using hardlinks, and set the "Copy On Modify" bit. This can be cleared of course as appropriate, where you want the origonal hardlink behaviour. > in the case of kernel, why not get the whole repository? > CVS stores versions as diffs internally, saving space. Yep good for kernel where there are no binaries, but not good in general. Padraig. - 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: Relative CPU time limit
man setrlimit (or ulimit) This is per user though, and only related to user accounting really as you can only set a limit on the number of CPU seconds used. I would also really like the ability to throttle any processes back to a certain % of CPU, and extending this to throttling users to certain CPU limits which would be useful also. Obviously you would set it up so that all available CPU is used, for e.g. if you had 2 CPU bound processes running and you allocated 1 to 40% and the other 60%, when either terminates the other should increase to the available CPU (I can't see any reason why you would forceably limit a process' CPU usage if there was free CPU). Could the current scheduling logic that uses the nice value of a process, do this, and all I would have to do is have a % specifying wrapper around this? Any other ideas or will I get hacking.. Padraig. Xuan Baldauf wrote: > Hello, (maybe a FAQ, but could not find this question) > > is it possible with linux2.4 to limit the relative CPU time > per process or per UID? I saw something like this about 5 > years ago on solaris machines, but I have not access to > solaris machines anymore. I do not mean limiting the > absolute CPU time (e.g. "the process should run 20minutes at > maximum and shall be killed after that time), but the > relative CPU time (e.g. "apache should consume at most 80% > of my servers CPU time and shall be throttled if it was to > consume more"). > > Thanx, > Xuân. :-) > - > 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/ - 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/
Re: Documenting stat(2)
[EMAIL PROTECTED] wrote: > In article <9463fj$gsq$[EMAIL PROTECTED]> you write: > >> Basically, the _only_ think you should depend on is that st_size >> contains: >> - for regular files, the size of the file in bytes >> - for symlinks, the length of the symlink. > > I don't think this is right - for a symlink, stat should return the > size of the file; lstat should return the size of the symlink. Nope stat should return the details of the symlink whereas lstat should return the details of the symlink target. But there is another ambiguity when stating symlinks. In the current implementation the length of the symlink (name) is the same as the symlink file size. Will this always be the case? If not then the above statement is wrong. i.e. >> - for symlinks, the length of the symlink. should be >> - for symlinks, the symlink file size in bytes (currently the >> length of the symlink). Padraig. - 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/
Re: Compact flash disk and slave drives in 2.4.2
Can I just confirm that I'm seeing the same thing.
I'm using a pcengines compact flash adapter which has
a master/slave jumper, and this seems to confirm what
I thought, I.E. slaves are OK. Note I also had trouble where
HD was master and flashdisk was slave, where again the
CF was silently ignored.
Padraig.
Richard Smith wrote:
> I spent most of the day today trying to track down why the embedded system I am
>working
> on would not recognize hdb on boot. It refused to show in the devices list even
>though I
> specifically told the kernel it existed with the hdb=c,h,s option.
>
> After working on what seemed like a hardware problem for quite a while I finally
>decided
> that there must be something flaky in the ide driver code and began to add some
>debug
> printk's
>
> In which I found the following in ide.c:
>
> /*
> * CompactFlash cards and their brethern pretend to be removable hard disks,
> * except:
> * (1) they never have a slave unit, and
> * (2) they don't have doorlock mechanisms.
> * This test catches them, and is invoked elsewhere when setting appropriate
> * config bits.
> *
> */
>
> Since hda in my system is a CompactFlash card I began to look further and then with
>some
> discovered the following in ide-probe.c
>
> /*
> * Prevent long system lockup probing later for non-existant
> * slave drive if the hwif is actually a flash memory card of some variety:
> */
> if (drive_is_flashcard(drive)) {
> ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit];
> if (!mate->ata_flash) {
> mate->present = 0;
> ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit]
> mate->noprobe = 1;
> }
> }
>
> Now perhaps I am just way out on the wacky edge of things but I don't agree with the
> above in the slightest. We use CF's in conjunction with slaves all the time.
>Almost all
> of our embedded devices boot from CF's and I routinely add a HD as a slave to the
>system
> to do developement with but it's always been under DOS.
>
> I comment out the check above and all is well... hdb shows up as expected.
>
> Can someone explain to me why the above check was added and if its continued
>existence is
> necessary? Whats this long system lockup thing mentioned?
>
> Even if there is some danger of a long lockup I suggest that at least a message that
>its
> ignoring hdb is the least it could do rather than sliently ignoreing it. Especially
>when
> I specifically told it a hdb existed via the command line. Shouldn't command line
> parameters take precidence?
>
> I not subscribed to the kernel-list so please copy me in the response.
>
> Thanks.
>
>
> --
> Richard A. Smith[EMAIL PROTECTED]
> "I'd hang out with science kids - they can blow things up!
> I mean, what's cooler than that?"
>- Tori Amos
>
>
> -
> 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/
-
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: Compact flash disk and slave drives in 2.4.2
OK the following assumes CF never have slaves which is just wrong.
The CF should be logically treated as an IDE harddisk. So the fix is
probably have a kernel parameter that causes the following check to
be skipped?
/*
* Prevent long system lockup probing later for non-existant
* slave drive if the hwif is actually a flash memory card of some
variety:
*/
if (drive_is_flashcard(drive)) {
ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit];
if (!mate->ata_flash) {
mate->present = 0;
ide_drive_t *mate =
&HWIF(drive)->drives[1^drive->select.b.unit]
mate->noprobe = 1;
}
}
But do we need this check? Is it just for speed. If you have an "ordinary"
harddrive as master with no slave, will the check for slave cause the same
"long system lockup", and if not, why.
Padraig.
Andre Hedrick wrote:
> Because in laptops, the primary use of CFA.
> Laptops using CFA do not have slaves.
-
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: Compact flash disk and slave drives in 2.4.2
How do you activate the walk around you describe
to allow the detection of the slave? hda=ataflash?
Is this sort of stuff documented anywhere?
For those interested you also mention it here:
http://lists.sourceforge.net/archives//linux-usb-devel/2000-August/000929.html
This describes the other combination that causes
a problem where you have a normal disk as master
and the CF as slave:
http://boudicca.tux.org/hypermail/linux-kernel/2000week25/0973.html
Again the problem unresolved:
http://boudicca.tux.org/hypermail/linux-kernel/2000week26/0174.html
cheers,
Padraig.
Andre Hedrick wrote:
> Because 'real' ATA devices use a signature map the detects presense of
> master slave during execute diagnostics. This is done in the BIOS.
> CFA does no report this correctly and waiting for a 31 second time out is
> not acceptable. If you have a complain take it to CFA commitee and have
> them fix it.
>
> I put in a walk around for having 2 CFA's to allow detection.
> This will work also if you call it for a CFA+Disk pair.
>
> On Tue, 27 Mar 2001, Padraig Brady wrote:
>
>> OK the following assumes CF never have slaves which is just wrong.
>> The CF should be logically treated as an IDE harddisk. So the fix is
>> probably have a kernel parameter that causes the following check to
>> be skipped?
>
> Logically treated, is true, but again CFA does not follow the rules of
> what the ATA committee gives them, and I refuse to break rules as the
> standard model. Rule breaking are exceptions.
>
> Also show me a case where a laptop will do master/slave in CFA.
>
>> /*
>>* Prevent long system lockup probing later for non-existant
>>* slave drive if the hwif is actually a flash memory card of some
>> variety:
>>*/
>> if (drive_is_flashcard(drive)) {
>> ide_drive_t *mate = &HWIF(drive)->drives[1^drive->select.b.unit];
>> if (!mate->ata_flash) {
>> mate->present = 0;
>> ide_drive_t *mate =
>> &HWIF(drive)->drives[1^drive->select.b.unit]
>> mate->noprobe = 1;
>> }
>> }
>>
>> But do we need this check? Is it just for speed. If you have an "ordinary"
>> harddrive as master with no slave, will the check for slave cause the same
>> "long system lockup", and if not, why.
>>
>> Padraig.
>>
>> Andre Hedrick wrote:
>>
>>
>>> Because in laptops, the primary use of CFA.
>>> Laptops using CFA do not have slaves.
>>
>
> Andre Hedrick
> Linux ATA Development
> ASL Kernel Development
> -
> ASL, Inc. Toll free: 1-877-ASL-3535
> 1757 Houret Court Fax: 1-408-941-2071
> Milpitas, CA 95035Web: www.aslab.com
-
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: Compact flash disk and slave drives in 2.4.2
I'm still confused :-( When you say: "CFA is dropped into a pcmica/cardbus thingy. Also there are no CFA's which are ATA devices by the definition, they require a host-bridge to transport the signal. Handling host-bridges is the problem. As more and stranger usages of these bridges happen the more screwy thing get." This is not the case I'm talking about. CF is not always off PCMCIA. Any CF I've used I can plug directly onto the IDE on the motherboard using a very simple passive adapter, detailed in the spec. For e.g. I use http://www.pcengines.com/cflash.htm In this mode it should be just treated as another ATA device IMHO. Padraig. Andre Hedrick wrote: > hdx=flash is only a flag to deal with flash. > > a better description is probe-slave-with-master-flash, or > to-hell-with-flash-go-look. > > On Tue, 27 Mar 2001, Richard A. Smith wrote: > >> On Tue, 27 Mar 2001 09:17:48 -0800 (PST), Andre Hedrick wrote: >> >>> not acceptable. If you have a complain take it to CFA commitee and have >>> them fix it. >> >> Well my only real complaints are that 1) It was done silently.. 2) I could not >override it >> w/o a code mod. Both of which are contrary to what I am accustom to when using >linux. > > Nothing is done privately or silently, sometime I try to second guess the > needs and add things so that when the question pops up, I can say, gee: > This was the guy that was going to ask that question, glad I had an early > answer. > > It was addressed some time ago when there was a case of a firewall box > using two CFA's in a HOST->CFA thingy. This was where hda/hdb were both > CFA's > > Override a probe that can hang a system is not going to happen. > You override the blocking flag first, then the generic overide is not > needed. > >>> Logically treated, is true, but again CFA does not follow the rules of >>> what the ATA committee gives them, and I refuse to break rules as the >>> standard model. Rule breaking are exceptions. >>> >>> Also show me a case where a laptop will do master/slave in CFA. >> >> Agreed... If CF does some wierd stuff then you shouldn't make the ATA driver break >any >> rules for it.. that wasn't what I was asking for. Just some why's and perhaps a >message >> that indicated what it was doing. > > The problem is that body does more things outside a commitee than it does > inside. So the docs do not reflect reality or impose usage rules. > >> As for the laptops.. What laptops are you refering to? Don't most of them have >some sort >> of std laptop HD or an ibm microdrive thing. CF is terribly expensive compared to >> mechanical HDs. > > CFA is dropped into a pcmica/cardbus thingy. > > Also there are no CFA's which are ATA devices by the definition, they > require a host-bridge to transport the signal. Handling host-bridges is > the problem. As more and stranger usages of these bridges happen the more > screwy thing get. > >>> /linux/drivers/ide/ide.c >>> * "hdx=flash" : allows for more than one ata_flash disk to be >>> * registered. In most cases, only one device >>> * will be present. >> >> Perhaps I missed something.. but this won't work for my original case. I have a CF >as hda >> and I was trying to hook up a mechanical HD as the slave. I specified hdb=c,h,s on >the >> command line but it was ignored. > > Again it is only a flag that allows for probing of a slave device if the > primary is a flash. > > Now if the reactions/responses are wrong then it needs a fix, but to allow > systems to hang because of a nonexistant device is not something Linus > will allow, period. - 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: New directions for kernel development
I actually agree with most these points, not. Many a true word was said in jest :-) Padraig. Linus Torvalds wrote: > Hi all, [snip] - 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: Cool Road Runner
OK can we just have a technical discussion? Andre Hedrick wrote: > On Mon, 2 Apr 2001, Steffen Grunewald wrote: > [hostilities snipped] > Also, several messages earlier I pointed out that I had not documented the > feature because it was only attempted once, and only with 2 CFA's in a > bazar ata-bridge. 1. All compact flash have an inbuilt ATA controller. I.E. they can be used exactly like a harddisk, directly off the IDE controller of a motherboard. I.E. no need for PCMCIA or any of that. I understood from your responses that you didn't realise this? 2. Compact Flash in this application (I.E. solid state hard disk) is getting very popular as prices are tumbling. 3. Having a config parameter (uneeded kludge in my opinion), like hdx=flash even if hdx is not a compact flash is confusing. Can we call it hdx=probe which fits nicely with the noprobe option. > I then explained why the detection was failing and pointed where to verify. No you didn't. You mentioned a 30 second timeout, but not why it was caused. Have you seen this yourself or can you point us at who reported this to you? > After 3-5 attempts and I can not get the point across because the other > party keeps going off in different directions to do "what about this", Emm, I think *you* were going off describing your application with a "bazar ata-bridge", not the simple use of a compact flash as a hard disk. > I finally pointed out facts that distrub people, and gave up on trying to > show/present/give the answer and offered to then enforce their beliefs of > reality. > > So I state a few facts very pointed to get their attention again and that > is additude?? Actually I thought the final email was a little more concise/informative, thanks. [more hostility snipped] Padraig. - 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: Cool Road Runner
Andre Hedrick wrote: > On Mon, 2 Apr 2001, Padraig Brady wrote: > >> OK can we just have a technical discussion? > > Please, lets do, I am tired of the battles > >> I.E. no need for PCMCIA or any of that. I understood from your >> responses that you didn't realise this? > > This valid that I do not know everything and that CFA does interesting > things more than what was specified in the past. cool. >> 2. Compact Flash in this application (I.E. solid state hard disk) is >> getting very popular as prices are tumbling. >> >> 3. Having a config parameter (uneeded kludge in my opinion), like hdx=flash >> even if hdx is not a compact flash is confusing. Can we call it hdx=probe >> which fits nicely with the noprobe option. >> >>> I then explained why the detection was failing and pointed where to verify. >> >> No you didn't. You mentioned a 30 second timeout, but not why it >> was caused. Have you seen this yourself or can you point us at who >> reported this to you? > > Sorry phone call and email got mixed togather. > But I did explain that there could be a failure to detect if PDIAG/DASP > if one or the other devices was held to long and the wrong device reported > a signature in the task register. Also that the if you reversed the two > device it would correctly report always. > Hmm, OK. >> >>> After 3-5 attempts and I can not get the point across because the other >>> party keeps going off in different directions to do "what about this", >> >> Emm, I think *you* were going off describing your application with >> a "bazar ata-bridge", not the simple use of a compact flash as a >> hard disk. > > Not quite, the electronic differences and flash in native mode is > incompatable, if you put it in to a mode that is 5V compatable then it > does seem possible and reasonable to work. Your imperical data points > verify this issue. cool > What really needs to happen is that all the devices that are CFA-like > which require name parsing for detecting should have the "flash" rule > imposed. Whereas the ones that correctly report 0x848A for word 0 of the > identify page may be exempt. sounds good if we can easily differentiate between buggy & non-buggy flash. > This seems like a reasonable step given that you are pointing out you > a have modern CFA's that are more than just CFA's. I'm not sure I have. They seem to following the latest spec I downloaded from www.compactflash.org > Would that work for you? > >>> I finally pointed out facts that distrub people, and gave up on trying to >>> show/present/give the answer and offered to then enforce their beliefs of >>> reality. >>> >>> So I state a few facts very pointed to get their attention again and that >>> is additude?? >> >> Actually I thought the final email was a little more concise/informative, thanks. > > Well I am glad that somebody gleened some information and providing > feedback so that forward progress is possible, and not the classic battles. cool, Padraig. - 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: CFA Membership (Re: Cool Road Runner)
Andre Hedrick wrote: > On Mon, 2 Apr 2001, Padraig Brady wrote: > >> I'm not sure I have. They seem to following the latest spec I >> downloaded from www.compactflash.org > > I am not paying $2500-$5000 annual for membership sorry. > It is bad enough that I burn $800 for T13 plus about $1000 per meeting. > $7000 is my personal financial limit. > > If you want to give me the SPEC to review and no NDA cool, but CFA and SDA > I have not interest in the legal action that will happen I expose SDA for > what it is ... I just filled a form on the WWW site and downloaded: "CF+ and CompactFlash Specificiation revision 1.4" Padraig. - 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.4.1-pre10 -> 2.4.1 klogd at 100% CPU ; 2.4.0 OK
Chris Hanson wrote:
>Date: Wed, 31 Jan 2001 17:48:50 +
>From: Padraig Brady <[EMAIL PROTECTED]>
>
>Are you using the 3c59x driver?
>
> Yes.
Can we sort this out once and for all? There are a few emails
everyday relating to this bug.
The following patch posted by "Troels Walsted Hansen" <[EMAIL PROTECTED]>
on Jan 11th fixes this. The problem is that when 2 consequtive
NULLs are sent to klogd it goes into a busy loop. Andrew Mortons
3c59x driver does this, but also on Jan 11th he replied that he had
fixed it. I'm using 2.4ac4 with no problems, so I presume some
of these patches have been lost along the way?
--- sysklogd-1.4.orig/klogd.cMon Sep 18 09:34:11 2000
+++ sysklogd-1.4/klogd.cThu Jan 11 09:26:10 2001
@@ -739,6 +758,13 @@
break; /* full line_buff or end of input buffer */
}
+ if( *ptr == '\0' ) /* zero byte */
+ {
+ ptr++;/* skip zero byte */
+ space -= 1;
+ len -= 1;
+ break;
+ }
if( *ptr == '\n' ) /* newline */
{
ptr++;/* skip newline */
-
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/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Obviously there has to be some standard base with which to work, especially for computer language keywords as these can't be converted due to name clashes. What would be cool is to pick a better base language than English that everyone would have to learn to "use computers". This is especially important for opensource as it would greatly ease the operation of the collective brain. Something easily parseable would be an obvious criterion and would allow us to interact with computers by voice(-recognition) with no ambiguity, etc. etc... tada: http://www.lojban.org/ will everything be changed over in the 2.5 timeframe? :-) Padraig. Ingo Oeser wrote: >On Sat, May 19, 2001 at 11:34:48AM -0700, Linus Torvalds wrote: >[Reasons] > >>So the "English is bad" argument is a complete non-argument. >> > >Jepp, I have to agree. > >English is used more or less as an communication protocol in >computer science and for operating computers. > >Once you know how to operate an computer in English, you can >operate nearly every computer in the world, because they have >English as default locale. > >Let's not repeat Babel please :-( > >PS: English is neither mine, nor Linus native language. Why do > the English natives complain instead of us? ;-) > > > And be glad that's not German, that has this role. English > sentences are WAY easier to parse by computers, because it > doesn't use much suffixes and prefixes on words and has very > few exceptions. Also these exceptions are eleminated from > command languages WITHOUT influencing readability and > comprehensability. > > > >Regards > >Ingo Oeser > - 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: jffs on non-MTD device?
Some (most?) CF disks have hareware wareleveling.
I use ext2 with e2compr patch.
Padraig.
Pavel Machek wrote:
>Hi!
>
>I'm trying to run jffs on my ATA-flash disk (running ext2 could kill
>some flash cells too soon, right?) but it refuses:
>
>if (MAJOR(dev) != MTD_BLOCK_MAJOR) {
>printk(KERN_WARNING "JFFS: Trying to mount a "
> "non-mtd device.\n");
>return 0;
>}
>
>What are reasons for this check?
>
> Pavel
>
-
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: Alan Cox quote? (was: Re: accounting for threads)
We'll yes it's true you can program everything like a state machine if the correct OS interfaces are there. I don't think they are though ATM. Also some things are more elegantly implemented using threads, whereas others are better as state machines. Padraig. David S. Miller wrote: >Dan Kegel writes: > > Alan, did you really say that, or are people taking your name in vain? > >He did say it, and I for one agree with him. :-) > >Later, >David S. Miller >[EMAIL PROTECTED] > - 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: ramdisk/tmpfs/ramfs/memfs ?
David Woodhouse wrote: >[EMAIL PROTECTED] said: > >> you could try using jffs2 on a RAM-simulated MTD partition. i think >>that would work but i have not tried it.. >> > >It works. Most of the early testing and development was done on it. It >wouldn't give you dynamic sizing like ramfs though. > >It would be nice to have a version of ramfs which compresses pages into a >separate backing store when they're unused. Shame somebody nicked the name >'cramfs' for something else, really :) > Hmm must look into getting ramfs working with http://linuxcompressed.sourceforge.net/ seems like the best of both worlds. Padraig - 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/
ramdisk/tmpfs/ramfs/memfs ?
Hi, I'm working on an embedded system here which has no harddisk. So, I can't swap to disk and need to have /var & /tmp in RAM. I'm confused between the various options for in RAM file- systems. At the moment I've created a ramdisk and made an ext2 partition in it (which is compressed as I applied the e2compr patch), which is working fine. Anyway questions: 1. I presume the kernel is clever enough to not cache any files from these filesystems? Would it ever need to? 2. Is tmpfs is basically swap and /tmp together in a ramdisk? The advantage being you need to reserve less RAM for both together than seperately? 3. If I've no backing store (harddisk?) is there any advantage of using tmpfs instead of ramfs? Also does tmpfs need a backing store? 5. Can you set size limits on ramfs/tmpfs/memfs? 6. Is a ramdisk resizable like the others. If so, do you have to delete/recreate or umount/resize a fs (e.g. ext2) every time it's resized? Do ramfs/tmpfs/memfs do this transparently? Are ramdisks resizable in kernel 2.2? 7. What's memfs? 8. Is there a way I can get transparent compression like I now have using a ramdisk+ext2+e2compr with ramfs et al? 9. Apart from this transparent compression, is there any other functionality ext2 would have over ramfs for e.g, for /tmp & /var? Also would ramfs have less/more speed over ext2? thanks, Padraig. - 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: ramdisk/tmpfs/ramfs/memfs ?
Thanks for all the replies! Would anyone have any objections to me writing a Documentation/ramdisks.txt or Documentation/filesystems/ram.txt as this stuff is very hard to find info on? Anyway seems like ramfs is the way to go with the limits patch applied. I loose compression, but gain as there is no data duplication in RAM, and also I don't need to preallocate space for a partition. If I understand correctly ramfs just points to the file data which are pages in the cache marked not to be uncached. Doh! is ramfs supported in 2.2? dwmw2 mentioned, for ramfs, it would be useful to compress unused pages (to someplace in RAM would be very good for my application), but I guess this would add a lot of complexity. btw I get my initial root filesystem from a compact flash that can be accessed just like a hardisk. It's writeable also like a harddisk, but we boot with it readonly, and only mount it rw if we want to save config or whatever. We definitely wouldn't swap to it as it has limited erase/write cycles. The filesystem is compressed ext2. I don't have swap so don't need tmpfs, but could probably use it anyway without a backing store? Anyway why was ramfs created if tmpfs existed, unless tmpfs requires backing store? They both seem to have been written around the same time? As for using JFFS2 + MTD ramdisk intead of ext2+e2compr+ramdisk is not an option as the only advantage would be journalling, you still can't resize. IMHO JFFS is only required where you have flash without an IDE interface. cheers, Padraig. Bjorn Wesen wrote: > > On Thu, 26 Apr 2001, Padraig Brady wrote: > > I'm working on an embedded system here which has no harddisk. > > So, I can't swap to disk and need to have /var & /tmp in RAM. > > I'm confused between the various options for in RAM file- > > systems. At the moment I've created a ramdisk and made an > > ext2 partition in it (which is compressed as I applied the > > e2compr patch), which is working fine. Anyway questions: > > Ouch.. yes you had to do stuff like that in the old days but it's very > cumbersome and inefficient compared to ramfs for what you're trying to do. > > > 1. I presume the kernel is clever enough to not cache any > >files from these filesystems? Would it ever need to? > > You always need to "cache" pages read. Because a page is the smallest > possible granularity for the MMU, and a block-based filesystem does not > need to be page-aligned, so it's impossible to do it otherwise in a > general way. > > > 3. If I've no backing store (harddisk?) is there any advantage > >of using tmpfs instead of ramfs? Also does tmpfs need a > >backing store? > > I don't know what tmpfs does actually, but if it is like you suggest (a > ramfs that can be swapped out ?) then you don't need it obviously (since > you don't have any swap). > > ramfs simply inserts any files written into the kernels cache and tells it > not to forget it. it can't get much more simple than that. > > > 5. Can you set size limits on ramfs/tmpfs/memfs? > > i don't think you can set a limit in the current ramfs implementation but > it would not be particularly difficult to make it work I think > > > 6. Is a ramdisk resizable like the others. If so, do you have > >to delete/recreate or umount/resize a fs (e.g. ext2) every > >time it's resized? Do ramfs/tmpfs/memfs do this transparently? > >Are ramdisks resizable in kernel 2.2? > > ramfs does not need any "resizing" because there is no filesystem behind > it. there is only the actual file data and metadata in the cache itself. > if you delete a file, it disapperas, if you create a new one new pages are > brought in. > > > 7. What's memfs? > > 8. Is there a way I can get transparent compression like I now > >have using a ramdisk+ext2+e2compr with ramfs et al? > > you could try using jffs2 on a RAM-simulated MTD partition. i think that > would work but i have not tried it.. > > > 9. Apart from this transparent compression, is there any other > >functionality ext2 would have over ramfs for e.g, for /tmp > >& /var? Also would ramfs have less/more speed over ext2? > > ramfs has all the bells and whistles you need except size limiting. and > obviously its faster than simulating a harddisk in ram and using ext2 on > it.. > > -bw > > - > 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/ - 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: ramdisk/tmpfs/ramfs/memfs ?
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > btw I get my initial root filesystem from a compact flash that can be > > accessed just like a hardisk. It's writeable also like a harddisk, but > > we boot with it readonly, and only mount it rw if we want to save > > config or whatever. We definitely wouldn't swap to it as it has > > limited erase/write cycles. The filesystem is compressed ext2. > > Why copy it into RAM? Why not use cramfs and either turn the writable > directories into symlinks into a ramfs which you create at boot time, or > union-mount a ramfs over the top of it? ? I never said I copied it into RAM. The ramfs is just used for /tmp & /var which are symlinks on the flash. I didn't know you could read/write cramfs like ext2/JFFS2? I still want to be able to update/create/delete files like a normal ext2 partition. Oh I see the confusion, sorry my fault, when I said the root filesystem is compressed ext2, I meant it's ext2 with chattr +c done on all files (the e2compr patch implmenents it). By the way why isn't e2compr a standard part of the kernel. I've have no problems at all with it. I didn't know about union-mounting, seems useful. As for whether to use tmpfs/ramfs I think they do basically the same thing only the implementation is different. tmpfs uses shared mem and so is probably more portable than ramfs which it tightly coupled with VFS. I think I'll use ramfs (with limits patch) so. > [EMAIL PROTECTED] said: > > As for using JFFS2 + MTD ramdisk intead of ext2+e2compr+ramdisk is not > > an option as the only advantage would be journalling, you still can't > > resize. IMHO JFFS is only required where you have flash without an IDE > > interface. > > True. We are currently lacking a compact, compressing, journalling > filesystem for use on block devices. It's been suggested that we could make > JFFS2 work on them, by making a fake MTD device which uses a block device > as backing store. Nobody's yet shown me the code though :) How much more efficent is JFFS than say ext3+e3compr, wrt: logic size/logic speed/RAM requirements/filesystem structure size. > -- > dwmw2 Padraig. - 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: bindprocessor
Look @ the processor sets plugin @ http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html Padraig. Andrew Morton wrote: >[EMAIL PROTECTED] wrote: > >>How can I bind a user space process to a particular processor in a SMP >>environment? >> > >You can't. > >Nick Pollitt had an implementation of prcctl() which does this >http://www.uwsg.indiana.edu/hypermail/linux/kernel/0102.2/0214.html > >I have a /proc based one at >http://www.uow.edu.au/~andrewm/linux/#cpus_allowed >- >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/ > - 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/
