> + res = bq27xxx_battery_voltage(di, );
> + if (res)
> + return res;
> +
> + mV = val.intval / 1000;
Reading that code I stumbled over the comment in
bq27xxx_battery_voltage saying that it returns millivolts. The code
here, the code in bq27xxx_battery_voltage and
> + res = bq27xxx_battery_voltage(di, );
> + if (res)
> + return res;
> +
> + mV = val.intval / 1000;
Reading that code I stumbled over the comment in
bq27xxx_battery_voltage saying that it returns millivolts. The code
here, the code in bq27xxx_battery_voltage and
> I am tempted to leave the "flags" argument in place though, along
> with the "MEMBARRIER_QUERY" flag. Thoughts ?
http://lwn.net/Articles/585415/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
I am tempted to leave the flags argument in place though, along
with the MEMBARRIER_QUERY flag. Thoughts ?
http://lwn.net/Articles/585415/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
> *
> ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE**
Is it really that bad to warrant this kind of warning? Not knowing
about the issue at all, I read from the original description that the
wastage is four pages of memory
*
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE**
Is it really that bad to warrant this kind of warning? Not knowing
about the issue at all, I read from the original description that the
wastage is four pages of memory times
> Another option would be to make a configure option to just ignore the
> date. I'm not sure if I would like to use MODSIGN when I have to fear
> that the machine wouldn't start when the RTC fails or got set to a wrong
> date.
Or just ignore the date unconditionally. After all, when a certificate
Another option would be to make a configure option to just ignore the
date. I'm not sure if I would like to use MODSIGN when I have to fear
that the machine wouldn't start when the RTC fails or got set to a wrong
date.
Or just ignore the date unconditionally. After all, when a certificate
In article you write:
> Interestingly, of the 26 configs that use EXPERT in the default
> clause, 15 of them are in drivers/hid (see below).
Without looking at the code I assume this is due to copy/paste.
Someone perhaps once wrote
> ./drivers/hid/Kconfig: default !EXPERT
when he really
In article e1tixga-0008t1...@www.xplot.org you write:
Interestingly, of the 26 configs that use EXPERT in the default
clause, 15 of them are in drivers/hid (see below).
Without looking at the code I assume this is due to copy/paste.
Someone perhaps once wrote
./drivers/hid/Kconfig: default
> 200Mb had been filled when it had been umounted from /mnt/bootf8
> repartitioned, mke2fs'd, a journal added and a new label written and then
> mounted to /amandatapes.
>
> Something it seems to me, should have forced the re-init, but didn't. So is
Something I stumbled across just a few days
200Mb had been filled when it had been umounted from /mnt/bootf8
repartitioned, mke2fs'd, a journal added and a new label written and then
mounted to /amandatapes.
Something it seems to me, should have forced the re-init, but didn't. So is
Something I stumbled across just a few days ago:
> Unaligned memory accesses occur when you try to read N bytes of data starting
> from an address that is not evenly divisible by N (i.e. addr % N != 0).
Should clarify that you mean "with power-of-two N" - even more
strictly this depends on the processor, but I'm pretty sure there is
none which
Unaligned memory accesses occur when you try to read N bytes of data starting
from an address that is not evenly divisible by N (i.e. addr % N != 0).
Should clarify that you mean with power-of-two N - even more
strictly this depends on the processor, but I'm pretty sure there is
none which
> In current architecture, you have to patch kernel IPv6 and IPv4
> protocols when you add new link layer that they don't recognize.
Which is right, because the IP layer is the place which knows how to
map IP addresses to link layer addresses.
IP must know its link layer. E.g. it needs a way to
In current architecture, you have to patch kernel IPv6 and IPv4
protocols when you add new link layer that they don't recognize.
Which is right, because the IP layer is the place which knows how to
map IP addresses to link layer addresses.
IP must know its link layer. E.g. it needs a way to
> This is a pity, because it would be so easy to make the both stacks
> totally independent of the actual link layers. It only needs one (or
> two) new function pointer in net_device. This function should do the
> conversion from IPv4/IPv6 address into corresponding hardware
> multicast/broadcast
This is a pity, because it would be so easy to make the both stacks
totally independent of the actual link layers. It only needs one (or
two) new function pointer in net_device. This function should do the
conversion from IPv4/IPv6 address into corresponding hardware
multicast/broadcast
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > I've replaced exportfs, mountd and nfsd with a newer version and it
> > works now.
>
> What version were you using? I would really like to know.
The system in question was built on a Knoppix release based on Debian
Potato, with updates from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've replaced exportfs, mountd and nfsd with a newer version and it
works now.
What version were you using? I would really like to know.
The system in question was built on a Knoppix release based on Debian
Potato, with updates from Woody.
> Will try your patch tomorrow.
...which does not change anything. (As expected.)
Olaf
-
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
Will try your patch tomorrow.
...which does not change anything. (As expected.)
Olaf
-
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> There is a place where a failed kstrdup could lead to this, but that
> is rather unlikely and wouldn't be as reproducible as this seems to
> be.
> If you boot up and then immediately shutdown does this error trigger,
> it does it have to be up for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is a place where a failed kstrdup could lead to this, but that
is rather unlikely and wouldn't be as reproducible as this seems to
be.
If you boot up and then immediately shutdown does this error trigger,
it does it have to be up for a
This is 100% reproducible. It hangs exportfs on shutdown.
Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 0040
Dec 4 19:50:13 glotze kernel: printing eip:
Dec 4 19:50:13 glotze kernel: c017254a
Dec 4 19:50:13 glotze kernel: *pde =
This is 100% reproducible. It hangs exportfs on shutdown.
Dec 4 19:50:13 glotze kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 0040
Dec 4 19:50:13 glotze kernel: printing eip:
Dec 4 19:50:13 glotze kernel: c017254a
Dec 4 19:50:13 glotze kernel: *pde =
In article <[EMAIL PROTECTED]> you write:
> The most recent one was yesterday: I had run lsusb in the morning and had no
> problems, but at the end of the day I ran it again, and after outputting 3
> lines of data, it hung, stuck in D-state. So now I have this:
>
> [/home/user]$ ps aux|grep D
>
In article [EMAIL PROTECTED] you write:
The most recent one was yesterday: I had run lsusb in the morning and had no
problems, but at the end of the day I ran it again, and after outputting 3
lines of data, it hung, stuck in D-state. So now I have this:
[/home/user]$ ps aux|grep D
USER
> kernel does know that it has been 'disconnected'. One can even justify the
> inconcsistent behavior -- the write definitely has no place to go (now), but
> the read can't be totally sure that there is no possible way anybody could
> ever find the other end and write to it.
For a socket created
kernel does know that it has been 'disconnected'. One can even justify the
inconcsistent behavior -- the write definitely has no place to go (now), but
the read can't be totally sure that there is no possible way anybody could
ever find the other end and write to it.
For a socket created
> Well, I understand that ipip_rcv does some work cleaning sk_buff.
> But why after that sk_buff cannot be submitted to ip_rcv, not
> netif_rx?
Oops, now I see that you're talking about ip_rcv, not netif_rx...
I'm doing roughly what you're proposing in CIPE (get IP packet
encapsulated in UDP
Well, I understand that ipip_rcv does some work cleaning sk_buff.
But why after that sk_buff cannot be submitted to ip_rcv, not
netif_rx?
Oops, now I see that you're talking about ip_rcv, not netif_rx...
I'm doing roughly what you're proposing in CIPE (get IP packet
encapsulated in UDP
> Yes, I was wrong. But is it possible in similar situation just call
> ip_rcv for the sk_buff?
What does "just call" mean? The additional setup done by the ipip
receiver is the minimum necessary to get the various parameters in the
sk_buff in a clean state (things like making sure all header
Yes, I was wrong. But is it possible in similar situation just call
ip_rcv for the sk_buff?
What does just call mean? The additional setup done by the ipip
receiver is the minimum necessary to get the various parameters in the
sk_buff in a clean state (things like making sure all header
> I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
> "unwrapping" tunelled IP packet creates "virtual Ethernet header" and submit
Does it? ipip_rcv() does this:
iph = skb->nh.iph;
skb->mac.raw = skb->nh.raw;
i.e. the "MAC header" pointer of the packet is
I read net/ipv4/ipip.c. It seems to me that ipip_rcv() function after
unwrapping tunelled IP packet creates virtual Ethernet header and submit
Does it? ipip_rcv() does this:
iph = skb-nh.iph;
skb-mac.raw = skb-nh.raw;
i.e. the MAC header pointer of the packet is the same as
> or such. tar/cpio and friends don't deal properly with
> a. holes inside of files.
> b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a
or such. tar/cpio and friends don't deal properly with
a. holes inside of files.
b. hardlinks between files.
GNU tar handles both of these. (Not particularly efficiently in the
case of sparse files, but that's a minor issue in this case.) See -S flag.
Perhaps more importantly, for a _robust_
> * you've ignored the robustness of design behind the UNIX kernel.
> These beasts keep going without falling apart even after serious injuries.
Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that
* you've ignored the robustness of design behind the UNIX kernel.
These beasts keep going without falling apart even after serious injuries.
Do you mean design or operation? In fact UNIX design has a number of
serious errors/problems, we just have gotten accustomed to it so much
that we
> This is guaranteed behaviour of UNIX. You get file handles in order, or
> you don't get them at all.
You get the _next free_ file handle in order. What if your program
assumes they are all contiguous, and it is called by some other
program which forgot about FD_CLOEXEC and has some higher fds
This is guaranteed behaviour of UNIX. You get file handles in order, or
you don't get them at all.
You get the _next free_ file handle in order. What if your program
assumes they are all contiguous, and it is called by some other
program which forgot about FD_CLOEXEC and has some higher fds
> Optimization use in select: If all "interesting" file id's are known
> to be below "n", then only the first "n" bits in a FD_ISSET need to
> be examined. As soon as the bits are scattered, it takes MUCH longer
> to check for activity
That's an optimization, not a correctness issue.
>
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection), programs _will_ break.
Of course, but this is a result from sloppy coding. In general, open()
can just return anything and
Ehh.. I will bet you $10 USD that if libc allocates the next file
descriptor on the first "malloc()" in user space (in order to use the
semaphores for mm protection), programs _will_ break.
Of course, but this is a result from sloppy coding. In general, open()
can just return anything and
> Still have to test copying from a SCSI disk on the same bus as the
> tape drive.
Done (tar c/tar d), no corruption.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> problems: just _how_ high woul dyou move it? Would it potentially disturb
> an application that opens thousands of files, and knows that they get
> consecutive file descriptors? Which is _legal_ and well-defined in UNIX.
Only if you close them before. The process may have been started with
I tested my systems to try to reproduce the recently reported SCSI
tape corruptions. I did not find any errors, the tape works OK.
Linux version 2.4.3 (olaf@bigred) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1
Sat Mar 31 11:51:54 CEST 2001
K6-III-400, 96MB
NCR53C815 SCSI controller
HP
I tested my systems to try to reproduce the recently reported SCSI
tape corruptions. I did not find any errors, the tape works OK.
Linux version 2.4.3 (olaf@bigred) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1
Sat Mar 31 11:51:54 CEST 2001
K6-III-400, 96MB
NCR53C815 SCSI controller
HP
problems: just _how_ high woul dyou move it? Would it potentially disturb
an application that opens thousands of files, and knows that they get
consecutive file descriptors? Which is _legal_ and well-defined in UNIX.
Only if you close them before. The process may have been started with
Still have to test copying from a SCSI disk on the same bus as the
tape drive.
Done (tar c/tar d), no corruption.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> Umm, no. Counters can be resetable - you just specify that accounting
> programs should not reset them, ever.
>
> The ability to reset counters is extremely useful if you're a human
> looking at the output of iptables -L -v. (I thus far know of no one
> who can memorise the counter values for
> > telling us the Tk library, which for 8 or 10 years has been pretty much
> > *the* X toolkit/widget set for scripting, does not include an interface
> > to X resources?
Of course it does; in an idiosyncratic way (not directly using X
resources) but it does use the X resource file syntax.
>
> Similarly, if my InPackets are at 102345 at one read, and 2345 the
> next read, and I know that my counter is 32 bits, then I know i've
> wrapped and can do my own math.
No. When you have resettable counters, you don't know if the counter
has wrapped or been reset. Either you have received
telling us the Tk library, which for 8 or 10 years has been pretty much
*the* X toolkit/widget set for scripting, does not include an interface
to X resources?
Of course it does; in an idiosyncratic way (not directly using X
resources) but it does use the X resource file syntax.
If it
Similarly, if my InPackets are at 102345 at one read, and 2345 the
next read, and I know that my counter is 32 bits, then I know i've
wrapped and can do my own math.
No. When you have resettable counters, you don't know if the counter
has wrapped or been reset. Either you have received 2345
Umm, no. Counters can be resetable - you just specify that accounting
programs should not reset them, ever.
The ability to reset counters is extremely useful if you're a human
looking at the output of iptables -L -v. (I thus far know of no one
who can memorise the counter values for
[Warning: historical reference ahead.]
> > I'd appreciate it if some of you with slow machines would try running
> > with fast mode on and seeing if that addresses the sluggishness.
>
> I assume that, eventually there will be no slow mode or fast mode
> distinction... just a single fast mode.
> And the problem is that this hits a fast path in the classical news spool
> layout article create path. The code for this assumes that you have
> articles in the range X to Y, and you just got a new article, so you write
> a file called /var/spool/news/group/name/Y+1. You really do not want to
>tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
I have a tool which compresses individual files in a tar archive
instead of the whole archive[1]. That one tries hard to write only in
standard 10kb blocks to emulate tar's behavior towards the drive.
I'll try in a few days (when I'm
tar cvf - . | gzip -9 | dd of=/dev/tapes/tape0 bs=32k
I have a tool which compresses individual files in a tar archive
instead of the whole archive[1]. That one tries hard to write only in
standard 10kb blocks to emulate tar's behavior towards the drive.
I'll try in a few days (when I'm back
[Warning: historical reference ahead.]
I'd appreciate it if some of you with slow machines would try running
with fast mode on and seeing if that addresses the sluggishness.
I assume that, eventually there will be no slow mode or fast mode
distinction... just a single fast mode. Right?
And the problem is that this hits a fast path in the classical news spool
layout article create path. The code for this assumes that you have
articles in the range X to Y, and you just got a new article, so you write
a file called /var/spool/news/group/name/Y+1. You really do not want to
> It scares me that peoples' messages would be denied based on what
> degree of connection they choose to mail via. I sincerely hope that
> the DUL lists only list netblocks that are actively being used for
> spam. This would be sort of like the Usenet Death Penalty, instating
> bans on providers
It scares me that peoples' messages would be denied based on what
degree of connection they choose to mail via. I sincerely hope that
the DUL lists only list netblocks that are actively being used for
spam. This would be sort of like the Usenet Death Penalty, instating
bans on providers who
> a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
> at all (except for the SMP vs UP issue) so it's not the same thing as
No, no, no. This is absolutely and dangerously wrong.
A module depends on the kernel configuration, because it may access
internal data structures of
a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
at all (except for the SMP vs UP issue) so it's not the same thing as
No, no, no. This is absolutely and dangerously wrong.
A module depends on the kernel configuration, because it may access
internal data structures of
> 1) The idea of letting a bug "expire" is a good one. One way to do this
> is to incorporate some form of user-base moderation into the bug
> database. Unlike some of the forum systems, there's no reason why we can't
> have tiers of moderators: "maintainers" are the clearinghouse people for
1) The idea of letting a bug "expire" is a good one. One way to do this
is to incorporate some form of user-base moderation into the bug
database. Unlike some of the forum systems, there's no reason why we can't
have tiers of moderators: "maintainers" are the clearinghouse people for
> sock_creat(PF_INET, SOCK_DGRAM, IPPROTO_UDP, );
> sin.sin_family = AF_INET;
> sin.sin_port = htons((unsigned short)serv_port);
> sin.sin_addr.s_addr = htonl(INADDR_ANY); /*i am not sure about this*/
Needs the target IP address here.
> msg.msg_name =
> msg.msglen = sizeof(struct sockaddr_in);
sock_creat(PF_INET, SOCK_DGRAM, IPPROTO_UDP, sock);
sin.sin_family = AF_INET;
sin.sin_port = htons((unsigned short)serv_port);
sin.sin_addr.s_addr = htonl(INADDR_ANY); /*i am not sure about this*/
Needs the target IP address here.
msg.msg_name = sin;
msg.msglen = sizeof(struct
> Yes, but if SMP for Athlons is not supported, what is the point in
> allowing CONFIG_SMP + CONFIG_MK7 (or CONFIG_SMP + CONFIG_MK6)? Such a
> kernel will not run on *any* SMP system, since AMD kernels do not work
> on Intel. If an AMD user really wants to carry around SMP baggage for
> no
Yes, but if SMP for Athlons is not supported, what is the point in
allowing CONFIG_SMP + CONFIG_MK7 (or CONFIG_SMP + CONFIG_MK6)? Such a
kernel will not run on *any* SMP system, since AMD kernels do not work
on Intel. If an AMD user really wants to carry around SMP baggage for
no reason,
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled, would be
> > acceptable.
>
> Using a different source port number, even.
I was not suggesting ignoring these. OTOH, there is no reason to treat an
RST packet as "go away and never ever send traffic to this host again" -
i.e. trying another TCP connection, this time with ECN disabled, would be
acceptable.
Using a different source port number, even.
But that
> I also really, really, *REALLY* hate them for killing serial ports. It's
> a Bad Idea[TM].
Why, it opens up the market for serial-ports-on-USB devices. HW
manufactures can make significantly more money on that than on $7.95
ISA multi I/O cards[1] ;-)
Olaf
[1] and I still dislike those,
I also really, really, *REALLY* hate them for killing serial ports. It's
a Bad Idea[TM].
Why, it opens up the market for serial-ports-on-USB devices. HW
manufactures can make significantly more money on that than on $7.95
ISA multi I/O cards[1] ;-)
Olaf
[1] and I still dislike those,
> i.e after the kernel calls ip_route_output() and
> ip_route_output_slow() and fails to find a match, i
> need the kernel to somehow "hook-up" with a
> process/daemon(routing protocol) and access a user
> route cache there.
You may try this: http://sites.inka.de/~bigred/sw/rrouted.txt>
Olaf
-
i.e after the kernel calls ip_route_output() and
ip_route_output_slow() and fails to find a match, i
need the kernel to somehow "hook-up" with a
process/daemon(routing protocol) and access a user
route cache there.
You may try this: URL:http://sites.inka.de/~bigred/sw/rrouted.txt
Olaf
-
To
In article <[EMAIL PROTECTED]> you write:
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
>...
> Those symbols are rather generic and rather
In article [EMAIL PROTECTED] you write:
[J Sloan]
The module now compiles and gets installed -
Unfortunately, attempting to load it does not go well:
kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
...
Those symbols are rather generic and rather important. Sounds
> this problem is that it would give any internet hackers the ability to
> discover the network topology (including which servers host NDS master
> and replica databases). Not very secure. The concern for Petr is if in
If knowing the server makes it vulnerable, the server has other
problems
> The original exploit had nothing to do with filenames masquerading as
> options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
Why is there any reason that a shell should be invoked anywhere in the
request_module->modprobe->insmod chain?
If implemented correctly, this attack
this problem is that it would give any internet hackers the ability to
discover the network topology (including which servers host NDS master
and replica databases). Not very secure. The concern for Petr is if in
If knowing the server makes it vulnerable, the server has other
problems
The original exploit had nothing to do with filenames masquerading as
options, it was: ping6 -I ';chmod o+w .'. Then somebody pointed out
Why is there any reason that a shell should be invoked anywhere in the
request_module-modprobe-insmod chain?
If implemented correctly, this attack should
The definition of for_each_task() in is based on
init_task. This symbol is exported in Linux 2.2.15 and 2.4.0-test9,
but with a comment which indicates only a special use; it is not
exported in 2.2.9.
Is there an official opinion about whether for_each_task() is intended
to be usable from a
The definition of for_each_task() in linux/sched.h is based on
init_task. This symbol is exported in Linux 2.2.15 and 2.4.0-test9,
but with a comment which indicates only a special use; it is not
exported in 2.2.9.
Is there an official opinion about whether for_each_task() is intended
to be
> Well it's safer if you are lazy about prototyping varargs functions.
> But of course by doing that you're treading on thin ice anyway, in
> terms of type promotion and portability. So I guess it's much better
> to say "varargs functions MUST be prototyped" and use the registers.
make
Well it's safer if you are lazy about prototyping varargs functions.
But of course by doing that you're treading on thin ice anyway, in
terms of type promotion and portability. So I guess it's much better
to say "varargs functions MUST be prototyped" and use the registers.
make
> We figured that since we are in user context (do_ioctl) and use
> spin_lock_bh() to protect us from other concurrent threads, it might
> interfere with rtnl_lock() so we remove our lock just before calling
> register_netdev() and lock again upon return but then the whole process just
> stopped
> > I suppose. Look at what you just stated! This means that a reported
> > value is now worthless.
>
> Correct. And it was always worthless.
Right. The module "use count" is not a use count, it's a lock count.
E.g. a driver may well increase this counter on open and then again
when in a
I suppose. Look at what you just stated! This means that a reported
value is now worthless.
Correct. And it was always worthless.
Right. The module "use count" is not a use count, it's a lock count.
E.g. a driver may well increase this counter on open and then again
when in a particular
We figured that since we are in user context (do_ioctl) and use
spin_lock_bh() to protect us from other concurrent threads, it might
interfere with rtnl_lock() so we remove our lock just before calling
register_netdev() and lock again upon return but then the whole process just
stopped and
> "MemTotal: %8lu kB\n"
> to something like
> "%8lu kB\n"
The latter form offers no significant advantage over the former at
all - there is nothing that can be expressed as
value
which can't also be expressed as
name: value
or
name=value
and the latter format is significantly easier to
"MemTotal: %8lu kB\n"
to something like
"memtotal%8lu kB/memtotal\n"
The latter form offers no significant advantage over the former at
all - there is nothing that can be expressed as
namevalue/name
which can't also be expressed as
name: value
or
name=value
and the latter format is
> See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a
Speaking of that file,
< Portability:Pointers are not always 32bits, people do not all have
< floating point and you shouldn't use inline x86 assembler in
< your driver without
See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a
Speaking of that file,
Portability:Pointers are not always 32bits, people do not all have
floating point and you shouldn't use inline x86 assembler in
your driver without careful
> > Still, it would be nice to recover that 4 MB when the system
> > doesn't have any memory left.
> Yup. The X server could give back the memory for some cases like the
> background without too much hackery.
Then Linux only needs to implement SIGDANGER, which has been talked
about for years...
> We really need a collection of include files that only
> define the manifest constants and structures used for
> communication with user space. These can then be used both
> by glibc and by the kernel. This yields includes
> and and the former defines a constant API.
> It ideally never
We really need a collection of include files that only
define the manifest constants and structures used for
communication with user space. These can then be used both
by glibc and by the kernel. This yields includes linux/foo.h
and kernel/foo.h and the former defines a constant API.
It
1 - 100 of 102 matches
Mail list logo
