On Tue, 15 May 2001, Jonathan Lundell wrote:
> At 7:36 PM +0200 2001-05-15, Mike Galbraith wrote:
> >On Tue, 15 May 2001, Jeff Golds wrote:
> >
> >> Hi folks,
> >>
> >> Found this bit of unused code in the i386 and sh architectures.
> >>As it's not being used, let's get rid of it. Also,
Hi,
sometimes the following messages appear in /var/log/messages:
May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for device 00:0e.0
May 13 14:24:41 sunny kernel: PCI: The same IRQ used for device 00:0a.0
"0e" is my PCI sound card, and "0a" is my PCI ethernet card. The messages
On Tuesday 15 May 2001 02:13, Jacky Liu wrote:
> Hi everyone,
>
> Mark, I got your point about the dma/udma stuffs. My hdparm setting is
> UDMA w/ MultiSector 16..
>
> I had recompiled my kernel and disabled the FB option but my linux box
> still hanged (another completely freeze) yesterday... Oh
Miles Lane <[EMAIL PROTECTED]> wrote on 15/5/01 17:41:
>Does your approach solve
>the problem of USB devices,
>like mice, that
>don't have device ID's of any
>sort, where topology is the
>only way to
>distinguish them?
yes, that's what the location part is for.
Bye...
-
To unsubscribe
> From: jalaja devi [mailto:[EMAIL PROTECTED]]
>
> I tried porting a network driver from kernel2.2.x to
> 2.4. When i tried loading the driver, it shows the
> unresolved symbols for
> copy_to_user_ret
> outs
> __bad_udelay
>
> Could anyone please tell me the corresponding fxns in 2.4.
You need
On Thu, 10 May 2001 [EMAIL PROTECTED] wrote:
> I disagree. "Not a typewriter" is part of Unix tradition, and ought
> to be retained as a historical reference. It's also an opportunity
> for "the uninitiated" to learn a little more and move a little closer
> to becoming "the initiated."
We
On Thu, 10 May 2001, Jorge Boncompte [DTI2] wrote:
> After the reboot, the keyboard was working 5 minutes and then it
> locked. The console was working. I rebooted the machine again and has
> been working for 2 days, that the keyboard gets locked again.
Just to make sure...
Did you check
Sorry, I couldn't think of any good flames that haven't already been
posted so I thought I'd be boring and post some code. ;-)
On Monday 14 May 2001 23:50, Daniel Phillips wrote:
> On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> > Daniel, you write:
> > > Now, if the check routine tells
On Tue, 15 May 2001, Andrea Arcangeli wrote:
> o fixed race in wake-one LIFO in accept(2). Apache must be compiled with
> -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT to take advantage of that.
>
> 00_wake-one-4
>
> Backport 2.4 waitqueues and in turn fixes an hanging condition in
On Tuesday May 15, [EMAIL PROTECTED] wrote:
>
> On Tue, 15 May 2001, Neil Brown wrote:
> >
> > Ofcourse setting the "queue" function that __blk_get_queue call to do
> > a lookup of the minor and choose an appropriate queue for the "real"
> > device wont work as you need to munge bh->b_rdev too.
Bug in include/linux/module.h. Patch against 2.2.19. This does not
explain your oops, the ksymoops message is a separate bug.
Index: 19.1/include/linux/module.h
--- 19.1/include/linux/module.h Tue, 12 Sep 2000 13:37:17 +1100 kaos
(linux-2.2/F/51_module.h 1.1.7.2 644)
+++
mirabilos wrote:
>
> Hi,
> I have got that patch with "movl %2,%%edx" and removing the tmp
> and still cannot compile with the same error message I posted yesterday.
> The problem seems to be that, with or without "inline", it seems to
> put a reference into main.o of arch/i386/boot/compressed.
I've set up a Pioneer 305S scsi dvd-rom on an old adaptec card using the
stock aic7xxx driver included with the 2.4.4 kernel (not the old_aic7xxx
one). Everything works well, except when trying to access an encrypted
file on a DVD. This ioctl from libcss fails:
static int _get_title_key(int fd,
Jonathan Lundell wrote:
>
> ...
> I *like* eth0..n (I'd like net0..n better). And I *can't* ask what
> eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik
> has proposed an extension to ethtool to help out this lack, but it's
> not in Linux today, and needs concrete
At 9:34 PM -0400 2001-05-15, Nicolas Pitre wrote:
>On Wed, 16 May 2001, Daniel Phillips wrote:
>
>> On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
>> > Personally, I'd really like to see /dev/ttyS0 be the first detected
>> > serial port on a system, /dev/ttyS1 the second, etc.
>>
>> There
> On Tue, 15 May 2001 18:04:35 +0930 (CST),
> Jonathan Woithe <[EMAIL PROTECTED]> wrote:
> >ksymoops 2.4.1 on i686 2.2.19. Options used
> >Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found
>in System.map. Ignoring ksyms_base entry
>
> module_list was added to
On Wed, 16 May 2001, Daniel Phillips wrote:
> On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
> > Personally, I'd really like to see /dev/ttyS0 be the first detected
> > serial port on a system, /dev/ttyS1 the second, etc.
>
> There are well-defined rules for the first four on PC's. The
Hi Linus,
here are a filemap.c fix and a slight addition, with the first
fix changed as discussed by email.
1) __find_page_nolock should only set the referenced bit
on an active page, otherwise a number of subsequent
reads from the same page within one page scan interval
can SEVERELY
Hi Linus,
the patch is regenerated against 2.4.5-pre2 and changed as
discussed with marcelo (the "+ inactive_target / 3" is gone).
Full description:
1) fix swap_amount() to never return a swap count larger than
the process' RSS and swap_out() to return immediately when
swapping out a
Anton Altaparmakov wrote:
>
> And how are you thinking of this working "without introducing new
> interfaces" if the caches are indeed incoherent? Please correct me if I
> understand wrong, but when two caches are incoherent, I thought it means
> that the above _would_ screw up unless protected
Woopsthis is for 2.4.5-pre2
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't mix.
This part of the whole ymfpci change is missing
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't
At 23:35 15/05/2001, H. Peter Anvin wrote:
>"Albert D. Cahalan" wrote:
> > H. Peter Anvin writes:
> > > This would leave no way (without introducing new interfaces) to write,
> > > for example, the boot block on an ext2 filesystem. Note that the
> > > bootblock (defined as the first 1024 bytes)
Daniel Phillips wrote:
>
> Sounds like "treat it like a file and it acts like a file, treat it
> like a directory and it acts like a directory".
>
The original plan was that you only could indirect through it; not
chdir() for example. One could do the whole enchilada, but then one
would have
On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
> Personally, I'd really like to see /dev/ttyS0 be the first detected
> serial port on a system, /dev/ttyS1 the second, etc.
There are well-defined rules for the first four on PC's. The ttySx
better match the labels the OEM put on the box.
--
On Tuesday 15 May 2001 22:51, Linus Torvalds wrote:
> On Tue, 15 May 2001, Alexander Viro wrote:
> > If you want them all to inherit it - inherit from mountpoint.
>
> ..which is exactly what the device node ends up being. The implicit
> mount-point.
>
> And which point, btw, it is completely
On Tuesday 15 May 2001 17:34, Linus Torvalds wrote:
> On Tue, 15 May 2001, Neil Brown wrote:
> > Ofcourse setting the "queue" function that __blk_get_queue call to
> > do a lookup of the minor and choose an appropriate queue for the
> > "real" device wont work as you need to munge bh->b_rdev too.
At 1:18 PM -0700 2001-05-15, Linus Torvalds wrote:
> > 1 (network domain). I have two network interfaces that I connect to
>> two different network segments, eth0 & eth1;
>
>So?
>
>Informational. You can always ask what "eth0" and "eth1" are.
>
>There's another side to this: repeatability. A
On Tue, May 15, 2001 at 11:44:23PM +, Thorsten Kranzkowski wrote:
> On Tue, May 15, 2001 at 03:08:01PM -0600, Jeff V. Merkey wrote:
> >
> >
> > Is anyone actuaslly using the /dev/sch0 interface for SCSI tape changers
> > in Linux? I noticed that the device definitions are present, but I do
On 16 May 2001 01:56:23 +0200, Tim Jansen wrote:
> On Wednesday 16 May 2001 01:16, David Brownell wrote:
> >Only if it's augmented by additional device IDs, such as the
> >"what 's the physical connection for this interface" sort of
> >primitive that's been mentioned.
> >[...]
> > I suppose that
I tried porting a network driver from kernel2.2.x to
2.4. When i tried loading the driver, it shows the
unresolved symbols for
copy_to_user_ret
outs
__bad_udelay
Could anyone please tell me the corresponding fxns in
2.4.
Thanks in advance
Jalaja
At 4:35 PM -0700 2001-05-15, David Brownell wrote:
>[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
>
>> I would have to agree that "stable" is critical to not driving people
>> crazy. In the case of AIX, once a device is enumerated, it will retain
>> the same name
Hello Tim ,
On Tue, 17 Apr 2001, Mr. James W. Laferriere wrote:
> On Tue, 17 Apr 2001, Tim Waugh wrote:
> > On Mon, Apr 16, 2001 at 05:54:41PM -0700, Mr. James W. Laferriere wrote:
> > > # /etc/printcap
> > > # Please don't edit this file directly unless you know what you are doing!
> >
> > I suppose that for network interface names, some convention for
> > interface ioctls would suffice to solve that "identify" step. PCI
> > devices would return the slot_name, USB devices need something
> > like a patch I posted to linux-usb-devel a few months back.
>
> This is crap.
Only
I believe thats why there are persistant superblocks on the RAID partitions.
You can switch them around, and it still knows which drive holds which RAID
partition... That's the only way booting off RAID works, and the only
reason for the "RAID Autodetect" partition type... you can find those
Hi,
I've put new experimental version of my generic HDLC code on
http://hq.pm.waw.pl/hdlc/ ( ftp://ftp.pm.waw.pl/pub/linux/hdlc/experimental/ )
Currently supported (hw drivers) are C101 and N2 (untested) boards.
Protocols supported:
- X.25 and PPP (via X.25 and syncppp routines)
- Frame Relay
On Wednesday 16 May 2001 01:16, David Brownell wrote:
>Only if it's augmented by additional device IDs, such as the
>"what 's the physical connection for this interface" sort of
>primitive that's been mentioned.
>[...]
> I suppose that for network interface names, some convention for
> interface
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is "cd". Which would
mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
That is why I feel a "name" of a device handle shouldnt set how a
On Tue, May 15, 2001 at 03:08:01PM -0600, Jeff V. Merkey wrote:
>
>
> Is anyone actuaslly using the /dev/sch0 interface for SCSI tape changers
> in Linux? I noticed that the device definitions are present, but I do not
> see any driver shipped in the standard base that actually uses it.
On Tue, 15 May 2001, Andrea Arcangeli wrote:
> Detailed description of 2.4.5pre2aa1 follows.
> 00_buffer-2
>
> Reschedule during oom while allocating buffers, still getblk
> can deadlock with oom but this will hide it pretty well as
> it won't loop in a tight loop anymore.
According to Alan Cox:
> Chip:
> > Wouldn't it be better just to *try* ioctls and see which ones work and
> > which ones don't?
>
> 1. We have overlaps
We all agree that overlaps need to be eliminated over time. In the
meantime, as a coping strategy: I'll bet you that for any two given
device
On Tue, 15 May 2001, David Brownell wrote:
> I suppose that for network interface names, some convention for
> interface ioctls would suffice to solve that "identify" step. PCI
> devices would return the slot_name, USB devices need something
> like a patch I posted to linux-usb-devel a few
[ Re why "physical" device IDs _should_ have a critical role in sysadmin ]
> I would have to agree that "stable" is critical to not driving people
> crazy. In the case of AIX, once a device is enumerated, it will retain
> the same name across reboots. Enough information is kept about each
>
Chip Salzenberg wrote:
> According to Alan Cox:
> > Given a file handle 'X' how do I find out what ioctl groups I should
> > apply to it.
>
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
As ioctl's is just numbers that can be valid but mean totally
> > The "eth0..N" naming is done RIGHT!
Only if it's augmented by additional device IDs, such as the
"what 's the physical connection for this interface" sort of
primitive that's been mentioned.
> Nothing to do with the kernel but, one should then argue that the
> current stuff in
David Bronwell writes:
> Linus writes:
> > Now, if we just fundamentally try to think about any device as being
> > hot-pluggable, you realize that things like "which PCI slot is this device
> > in" are completely _worthless_ as device identification, because they
> > fundamentally take the
Hi Alan,
Thanks for getting back to me.
I wonder if DFI has a bios or chipset patch available and whether that would
help ?
Maybe disabling the VIA chipset support in the kernel and running generic
drivers would help ?
Thanks.
Keep up the good work anyways !
Regards
David Wilson
Technical
> I think I've found a serious bug in AMD Athlon page_alloc.c routines in
there's nothing athlon-specific there.
> correct on the DFI AK75-EC motherboard, if I set the CPU kernel type to 586
> everything is 100%, if I use "Athlon" kernel type I get:
> kernel BUG at page_alloc.c:73
when you
Here is a patch for 2.4.4. linux_logo_bw is used in hgafb.c, which
can be compiled as a module. But linux_logo_bw is not exported.
H.J.
---
--- linux-2.4.4-ac9/drivers/video/fbcon.c.mod Tue May 15 15:39:17 2001
+++ linux-2.4.4-ac9/drivers/video/fbcon.c Tue May 15 15:40:18 2001
@@
> it refuses to show any drives and i cant get the management
> software to work. so my question is this:
> has anyone with this card gotten it to work under linux
> 2.4.4-acX? if so, how?
Mine works. In fact the 2.4.4ac source tree currently lives on it.
> > Graphics cards are the same way. Especially high end ones. They have pipes
> > as well. For low end cards you can think of them as single pipeline cards
> > with one pipe.
>
> It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
> write(). It's a natural way to feed
> This way you can detect new disks, adapter cards, serial ports, etc. any
> time after the system is up. All disks are identified as "/dev/hdiskX",
I bet it will go in as /dev/hdiscX ;-)
(I prefer disk)
But I wish you to not vanish the scheme in which one can also address a
given device by
Hi,
I have a megaraid 466 controller, which both ami and the linux
kernel say is supported under 2.4.4, I tried the ami patches to
the drivers in the vanilla kernel to no avail, the card works
under windows...the card is even detected under linux now, but
> According to Alan Cox:
> > Given a file handle 'X' how do I find out what ioctl groups I should
> > apply to it.
>
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
You can do this with the tty layer. Just open /dev/tty and try tioclinux.
On my
> > > I couldn't agree with you more. It gives me headaches at work. One note,
> > > their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> > > etc. I personally which they use eth0.
> >
> > USB to USB networking cables aren't ethernet.
>
> I'm talking about a wireless
Alex Bligh writes:
> Q: Let us assume you have dynamic numbering disk0..N as you suggest,
>and you have some s/w RAID of SCSI disks. A disk fails, and is (hot)
>removed. Life continues. You reboot the machine. Disks are now numbered
>disk0..(N-1). If the RAID config specifies using
Anders Fugmann writes:
> I'm not sure where to put this in my Makefile.
> (tried, but it did not help)
> Could you please send an example.
See fs/Makefile or fs/msdos/Makefile for examples. I assume you are
building your module under the kernel tree?
Cheers, Andreas
--
Andreas Dilger \ "If a
Hi all, howzit going ? ;-)
Maybe I'm being dumb but I've been working with Linux long enough not to
make a silly mistake *I hope*.
I think I've found a serious bug in AMD Athlon page_alloc.c routines in
kernel 2.4.4.
I'm running an AMD athlon 850 running at 100x8.5, everything is setup
correct
Alan Cox wrote:
>
> > 1. is of course a problem in itself. Someone who creates overlapping
> > ioctls should be spanked, hard.
>
> No argument there. But there is no LANANA ioctl body
>
I though Michael Chastain was maintaining this set. No, we haven't made
it an official LANANA function,
"Albert D. Cahalan" wrote:
>
> H. Peter Anvin writes:
>
> > This would leave no way (without introducing new interfaces) to write,
> > for example, the boot block on an ext2 filesystem. Note that the
> > bootblock (defined as the first 1024 bytes) is not actually used by
> > the filesystem,
> Even if we have per-device filesystems, we are going to have the same
> issue, in one form or another. If we have a "/devicetype" trailing
> component added on, then somewhere it has to report "CD-ROM" or "cd"
> or "Compact Disc".
When I ask it. Not when I name it
-
To unsubscribe from this
On Tue, 15 May 2001, Richard Gooch wrote:
> Me The device name authority (Peter). Whoever. If you want
> Peter to bless it, then fine. But the standard is there. Violators
> will be persecuted.
Ah, standard on names in devfs? About as relevant as GOSIP...
-
To unsubscribe from this list:
> > >Keep it informational. And NEVER EVER make it part of the design.
> >
> > What about:
> >
> > 1 (network domain). I have two network interfaces that I connect to
> > two different network segments, eth0 & eth1;
>
> So?
>
> Informational. You can always ask what "eth0" and "eth1" are.
Richard Gooch wrote:
>
> Even if we have per-device filesystems, we are going to have the same
> issue, in one form or another. If we have a "/devicetype" trailing
> component added on, then somewhere it has to report "CD-ROM" or "cd"
> or "Compact Disc".
>
Again, many device types aren't
H. Peter Anvin writes:
> This would leave no way (without introducing new interfaces) to write,
> for example, the boot block on an ext2 filesystem. Note that the
> bootblock (defined as the first 1024 bytes) is not actually used by
> the filesystem, although depending on the block size it may
> 1. is of course a problem in itself. Someone who creates overlapping
> ioctls should be spanked, hard.
No argument there. But there is no LANANA ioctl body
> Agreed, but "determining type of device" and "determining if interface X
> is available on this device" are different operations. If
> And my opinion is that the "hot-plugged" approach works for devices even
> if they are soldered down ...
Yep. Though I tend to look at the whole problem as "autoconfiguration"
lately. Solving device naming (even the major/minor subproblem) is only
one part of having a complete
Alan Cox writes:
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a
Richard Gooch wrote:
>
> Alexander Viro writes:
> >
> >
> > On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > > Alan Cox writes:
> > > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > > fprintf
Alexander Viro writes:
>
>
> On Tue, 15 May 2001, Richard Gooch wrote:
>
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
>
> Type of filesystem where the file came from? Sure.
Who says it comes from only one - even on devfs that is not true
/dev/disk/4 is quite possibly
disk
scsi-disk
scsi-device
usb-scsi-device
usb-device
all at once
-
To unsubscribe from this list: send
Hi.
Thanks for your reply.
I'm not sure where to put this in my Makefile.
(tried, but it did not help)
Could you please send an example.
Thanks in advance.
Anders Fugmann
Andreas Dilger wrote:
>>
> I just recently had this problem, and your Makefile is missing:
>
> export-objs := .o
>
>
> > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > exit (1);
> >
> > And on my box cd is the cabbage dicer whoops
>
> Actually, no, because it's guaranteed that a trailing "/cd" is a
> CD-ROM. That's the standard.
Alan Cox wrote:
>
> > Wouldn't it be better just to *try* ioctls and see which ones work and
> > which ones don't?
>
> 1. We have overlaps
>
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
> 2. I've seen code where people play clever
> Wouldn't it be better just to *try* ioctls and see which ones work and
> which ones don't?
1. We have overlaps
2. I've seen code where people play clever ioctl tricks to deduce a device
type and it ends up looking like one of those chemistry identification
charts (hopefully minus do you see
> I couldn't agree with you more. It gives me headaches at work. One note,
> their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> etc. I personally which they use eth0.
>
The packet framing is quite different so it doesnt really make sense. For
wireless it does use
Patch turns s_lock+s_wait combination into semaphore.
wait_on_super() is dead. lock_super() is down(>s_lock),
unlock_super() is up(...).
One place is still ugly - get_super(), but that'll have to
wait until we add reference counters on superblocks. For the time being
get_super()
Juri Haberland wrote:
>
> Andrew Morton wrote:
>
> > For non-modular drivers things are less easy. If you
> > want to force it to use 10baseT (if_port zero) then
> > it should work OK if you cheat and use mem_start=0x400.
> > So `ether=0,0,0x400'.
> >
> > For BNC, it should work just fine with
On 15 May 2001 13:26:58 -0700, Dan Hollis wrote:
> This thread is becoming high enough volume and likely to become much more
> so, perhaps a separate ml should be set up for it? linux-device-management
> perhaps?
I agree that this is going to be a very high-volume discussion. OTOH,
this
Chip Salzenberg wrote:
>
> According to H. Peter Anvin:
> > A device can inherently belong to multiple device classes, and it
> > really should be thought of as such.
>
> And then there are layering technologies like LVM and loopback.
> They should be included in a discovery, but if you limit
According to H. Peter Anvin:
> A device can inherently belong to multiple device classes, and it
> really should be thought of as such.
And then there are layering technologies like LVM and loopback.
They should be included in a discovery, but if you limit yourself
to one "device type", there's
The main features of 2.2.20pre2aa1 are:
o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert)
o Support for 2T of RAM on alpha (me)
o RAW-IO (doable with bigmem enabled too). Improvements are also been
backported from 2.4.
o SMP scheduler improvements.
According to James Simmons:
> Graphics cards are the same way. Especially high end ones. They have pipes
> as well. For low end cards you can think of them as single pipeline cards
> with one pipe.
It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use
write(). It's a natural way
According to Johannes Erdfelt:
> I had always made the assumption that sockets were created because you
> couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> to have a file for every possible IP address/port you can communicate
> with.
I think you're right on both counts,
Detailed description of 2.4.5pre2aa1 follows.
---
00_alpha-illegal-irq-1
Be verbose for MAX_ILLEGAL_IRQS times if an invalid irq number
is getting run.
(debugging)
00_alpha-ksyms-1
Export
Andrew Morton wrote:
>
> Juri Haberland wrote:
> > Do you use 10Base2 (aka cheaper net)?
> > I do and after upgrading to 2.4.3 (I think) I had to force the driver to
> > use the BNC connector though the card was configured (via the little config
> > program supplied by 3com) to always use the
Alexander Viro wrote:
>
> On Tue, 15 May 2001, Chip Salzenberg wrote:
>
> > According to Linus Torvalds:
> > > I don't see why we couldn't expose the "driver name" for any file
> > > descriptor.
> >
> > Is it wise to assume that there is only one such name for *any* file
> > descriptor?
>
>
Anders Fugmann writes:
> I've got a simple question - how export symbols from one module, and use
> them in another.
>
> I have two modules - 'kvaser' and 'can_master'.
> 'kvaser' exports some functions, and 'can_master' needs to use call
> these functions.
>
> I used EXPORT_SYMBOL, and
On Tue, May 15, 2001 at 10:29:38PM +0100, Alex Bligh - linux-kernel wrote:
> > The argument that "if you use numbering based on where in the SCSI chain
> > the disk is, disks don't pop in and out" is absolute crap. It's not true
> > even for SCSI any more (there are devices that will aquire their
> > Yes. And we also use write to send data to printer. So what? Nobody makes
> > you use the same file.
>
> You're talking about /dev/fb0 vs. /dev/fb0ctl, right?
No. We are talking about a fbdev filesystem versus what we have now.
See later in the thread.
-
To unsubscribe from this list:
> > I couldn't agree with you more. It gives me headaches at work. One note,
> > their is a except to the eth0 thing. USB to USB networking. It uses usb0,
> > etc. I personally which they use eth0.
>
> USB to USB networking cables aren't ethernet.
I'm talking about a wireless connection.
Andrzej Krzysztofowicz wrote:
>
> Hi,
> The following patch cleans up a bit usage of parameters related to
> number of minors per disk in the SCSI subsystem. This is a preliminary
> patch and it seems to not contain any problematic changes. The full version
> of the patch (that allows to
On Tue, May 15, 2001 at 02:02:29PM -0700, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >On Tue, 15 May 2001, H. Peter Anvin wrote:
> >
> >> Alexander Viro wrote:
> >> > >
> >> > > None whatsoever. The one thing that matters is that noone
Hi there,
in fact I had the same problem with ide-scsi that you mentioned.
I also tried the kernel version 2.4.4 but it did not solve the problem.
I have a CD-RW drive (/dev/hdd resp. /dev/sr1) that was fully functional even
in ide-scsi mode. I also have a CD-ROM drive (/dev/hdb resp. /dev/sr0)
Linus Torvalds <[EMAIL PROTECTED]> [01/05/15 16:28]:
>
> The "eth0..N" naming is done RIGHT!
Nothing to do with the kernel but, one should then argue that the
current stuff in /etc/sysconfig/network-scripts is broken for hotplug as
placing a new network adapter into your bus will renumber your
Linus writes:
> And my opinion is that the "hot-plugged" approach works for devices even
> if they are soldered down - the "plugging" event just always happens
> before the OS is booted, and people just don't unplug it. So we might as
> well consider devices to always be hot-pluggable, whether
According to Linus Torvalds:
> I don't see why we couldn't expose the "driver name" for any file
> descriptor.
Is it wise to assume that there is only one such name for *any* file
descriptor?
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board,
> Hi,
> The following patch cleans up a bit usage of parameters related to
> number of minors per disk in the SCSI subsystem. This is a preliminary
> patch and it seems to not contain any problematic changes. The full version
> of the patch (that allows to succesfully change SCSI_MINOR_SHIFT
According to Alexander Viro:
> On Tue, 15 May 2001, James Simmons wrote:
> > I would use write except we use write to draw into the framebuffer. If I
> > write to the framebuffer with that data the only thing that will happen is
> > I will get pretty colors on my screen.
>
> Yes. And we also
On Tue, May 15, 2001, James Simmons <[EMAIL PROTECTED]> wrote:
> > Personally, I'd really like to see /dev/ttyS0 be the first detected serial
> > port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of
> > different serial hardware with all their own drivers and /dev entries.
1 - 100 of 625 matches
Mail list logo
