* Re: Modules and dll
From: Jesse Pollard @ 2002-12-12 16:17 UTC (permalink / raw)
To: Alexandre Pires, linux-kernel
In-Reply-To: <03d501c2a1fe$7b371dd0$6400a8c0@sawamu>
On Thursday 12 December 2002 10:49 am, Alexandre Pires wrote:
> Hi,
>
> We could compare the modules programs of linux with dlls of Windows ?
> Exist many differences between them (in relation to the functioning) ?
no. Windows DLLs are more like shared libraries. They are easily replaced (if
inactive), and do not directly destroy the system if missing.
DLLs are connected to applications via subroutine calls (Win DLL and shared
libraries), modules are usually accessed via special files, or system calls.
There is no direct linking (by memory mapping the module code to the user
mode application). Shared libraries are done this way.
Modules are closer to the device drivers in windows, which is what most
modules support. They can also support extending the OS by adding
additional capabilities - TCP/IP, IPv4, and IPv6 come to mind as some of the
most used, followed by the loadable binary interpretation (elf vs a.out).
Another difference is the way they are used - modules are loaded into
kernel mapping either by a kernel resident loader, or a userspace tool that
does the same. Shared libraries and DLLs are just put on disk where the
applications have been linked to expect them (or use an environment
variable to provide a search list of places to look when the application is
run.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
^ permalink raw reply
* Re: [PATCH] declare and export scsi_bus_type
From: Patrick Mochel @ 2002-12-12 16:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Matt Domsch, linux-scsi
In-Reply-To: <20021212091203.A21539@infradead.org>
> On Wed, Dec 11, 2002 at 07:46:22PM -0600, Matt Domsch wrote:
> > Below please find a patch, written by Pat Mochel, to declare and export
> > scsi_bus_type. My EDD code requires this to be exported in order to walk
> > the list of SCSI devices to match what BIOS discovered.
>
> I'm very unhappy with exporting random parts of the scsi midlayer. In
> what way do you need it? How does your code work with modular scsi?
It's a not a random piece. It's a symbolic representation of the scsi bus
type. It is designed to be exported for modular and optional components to
use.
EDD is a perfect example of this. It parses the firmware and obtains data
about the installed hard disks. It needs to associate the physical
hardware with the firmware data. So, it iterates over the SCSI (and soon
IDE, I believe) drives, searching for a match. It uses scsi_bus_type
because it uses the helper
int bus_for_each_dev(struct bus_type * bus, struct device * start, void * data,
int (*fn)(struct device *, void *));
Exporting the bus type keeps EDD at a good level of abstraction: it is
ia32-specific, so it can remain in arch/i386/ in a single source file, and
out of drivers/scsi/ and drivers/ide/. Instead of splitting the
functionality between those three places.
The bus type is accessible anyway, via the driver mdoel core. A piece of
code can iterate over the registered bus types and find the one named
'scsi', so it's by no means inaccessible. On the other hand, I can export
a call 'find_bus()' to search the bus-space for a bus with a certain name,
but that is much less efficient that dereferencing an explicit pointer.
-pat
^ permalink raw reply
* Re: Question on swapping
From: Joseph A Knapka @ 2002-12-12 15:56 UTC (permalink / raw)
To: Amol Kumar Lad; +Cc: Martin Maletinsky, linux-mm, kernelnewbies
In-Reply-To: <1039224592.4551.57.camel@amol.in.ishoni.com>
Amol Kumar Lad wrote:
>For the first time P would never be found in the swap cache, infact
> try_to_swap_out shall do following
> a] Page is dirty (in page table entry), so set PG_DIRTY in struct page
This appears to be the *only* place in the kernel where pte dirty
bits are propagated into the mem_map.
> b] Allocate a swap entry and add this page to swap cache
> c] release the page, and add the modify page table entry to point it to
> swap entry
>
> Now We have
> a] Page table entry for P contains swap info
> b] Page P in swap cache
> c] PG_DIRTY _is_ set (infact for a page in swap cache this is always
> true)
>
> Do remember, along with the swap cache P may be party of inactive_dirty
> list.
>
> The actual swapping to backing store is done by page scanner.
> It shall do following. Assume it has decided to _really_ free P
> 1] As page is dirty, call the page write back function. Thus here for
> the first time page found its place in swap.
> 2] send P back home, to buddy allocator
>
> If process A again access the page, then page fault handler shall do
> following
> 1] allocate a swap cache page
> 2] read the page from swap.
> 3] Modify page table entry of A to point to this page
So now the page is not marked dirty in the mem_map. What if A *now*
writes the page and then tries to swap it out? That's Martin's question:
in that case, we have a page that's in the swap cache; whose
page struct is *not* marked dirty; but which *is* actually dirty.
How do we know the page will be kept up to date on disk?
I used to understand how this worked, but I've forgotten. Or
maybe I never really understood it.
Cheers,
-- Joe
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* RE: policy administration
From: Frank Mayer @ 2002-12-12 15:51 UTC (permalink / raw)
To: 'Serge E. Hallyn', 'selinux'
In-Reply-To: <20021130022643.A8018@escher.cs.wm.edu>
Sorry I missed this message earlier, we are doing some work in this
area. See our web site (www.tresys.com/selinux) which has information
about released tools...within a week or two we're releasing updated
versions of our tools and a new *basic* policy browser/editor/config
tool.
Frank
> -----Original Message-----
> Behalf Of Serge E. Hallyn
> Sent: Saturday, November 30, 2002 2:27 AM
> To: selinux
> Subject: policy administration
>
> Hi,
>
> For the past, er, while, I've been working on tools for dealing
> with DTE policies. I'd now like to start applying that to selinux
> policies. Briefly, the work spanned from the extremely mundane
> (a gui policy editor) to the somewhat less mundane (presenting
> graphical representations of relations in policies) to the
> stuff I enjoyed more (constructing policies from modules, and
> analyzing policies using other MAC systems - ie using the BLP
> star-property to introduce relations on types, in a manner similar
> to what TIS did in 1998 to allow automatic policy updates*).
>
> I've been looking at the website and the mailing list, and it
> doesn't seem anyone is doing anything like this just yet. If
> anyone is, please let me know.
>
> thanks,
> -serge
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: COUNTING in FORWARD.
From: Remigiusz Kosztowny @ 2002-12-12 15:50 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <003301c2a1f4$91578780$bea83050@kacza>
[...]
> [root@bridge root]# iptables -xvnL FORWARD | head -n 3
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> 0 0 get-http tcp -- * eth1 0.0.0.0/0
> xx.xx.xx.0/24 tcp spt:80
> 0 0 put-http tcp -- * eth0 xx.xx.xx.0/24
> 0.0.0.0/0 tcp dpt:80
Sorry for my mistake. Should be:
[root@bridge root]# iptables -xvnL FORWARD | head -n 4
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 get-http tcp -- * eth1 0.0.0.0/0
80.48.168.0/24 tcp spt:80
0 0 put-http tcp -- * eth0 80.48.168.0/24
0.0.0.0/0 tcp dpt:80
pkts and bytes are equal zero, why? In 2.4.19 it's OK, in 2.4.20 not.
^ permalink raw reply
* Re: ospmd or acpid
From: Matthew Tippett @ 2002-12-12 15:48 UTC (permalink / raw)
To: Knut Neumann; +Cc: Matthew Tippett, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <004c01c2a2bc$d19bdf80$8cfa6386-naq7wT523jg@public.gmane.org>
Thanks, you answered the question.
So I will be sticking with acpid until all the ACPI support for my
system is under control ;).
Matt
Knut Neumann wrote:
>>Just a quick question regarding the user space daemons for ACPI. There
>>is ospmd which is part of the acpi project, and there is acpid which is
>>a seperate project which Andrew is a member of both.
>
>
> Hmm...so what is your question? I assume you meant to ask which daemon to
> use, so if thats right read on:
>
> While acpid already reached version 1.0 and is quite ready to use, ospmd is
> supposed to be better of the two but it is still under development - though
> actually no one is really working on it. When its done it should replace not
> only acpid but also apmd and it is thought to handle UPSes and other power
> related devices as well.
>
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: 2.4.20 and data logging
From: Chris Mason @ 2002-12-12 15:47 UTC (permalink / raw)
To: Anders Widman; +Cc: reiserfs-list
In-Reply-To: <17043452890.20021203231413@tnonline.net>
On Tue, 2002-12-03 at 17:14, Anders Widman wrote:
> > On Tue, 2002-12-03 at 06:38, Russell Coker wrote:
> >> How is data logging work going? Is there a patch for 2.4.20?
>
> > I'm trying to sort out a complete fix for the transaction overflow bug
> > Philippe hit, but other than that the patches are considered stable.
>
> Are these complete and working yet?
The current status is they are almost ready. The mmania guys hit a
slightly different overflow bug which we've also fixed, and we are
waiting on some final testing to say for sure.
-chris
^ permalink raw reply
* [linux-lvm] 자비출판 안내[시집,수필,소설,경제,경영,처세 기타][광고]
From: 줄판안내 @ 2002-12-12 15:47 UTC (permalink / raw)
To: linux-LVM
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
원고중개, 자비출판, 자서전, 기획출판 등 출판서비스 전문회사 자비출판 안내(시집,수필,소설,경제,경영,처세,기타)
linux-LVM님께 행복이 함께하시기를 빕니다.
귀하의 메일주소는 웹서핑중에서 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다. 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한[광고] 메일입니다
수신거부를 원하시면 여기를 클릭하기만 하세요~
[자비출판의 자세한 내용]
저작권사항
저자의 사상과 철학을 담아 품위있는 책으로 만들어 드립니다. 출판등록과 국제 문헌번호(ISBN)를 부여해 드립니다.
국립중앙도서관에 납본하여 언제라도 열람하실 수 있습니다.
저작권을 철저하게 보장합니다. 제작방법
노련한 운영으로 제작비를 최대한 절약하여 저렴한 비용이 듭니다.
철저하게 저자의 의도를 100% 반영합니다.
본문과 표지의 교정지를 최소한 두 번 이상 보내드립니다.
저자의 OK사인이 나야만 제작에 들어갑니다.
공격적인 경영으로 거래서점을 하루도 빠지지 않고 방문하여 도서의 진열상태를 수시로 점검하고, 더욱 좋은 자리에 진열될 수 있도록 최선을 다합니다. 인세 계약방식
처음 제작비의 일부를 저자가 부담하는 것 외에 일반 출판물과 동일한 계약 추가비용 전혀 없으며 책이 잘 팔리면 저자에게 인세를 지속적으로 지급 10% 선인세
자세한 사항은 도서출판 작은숲에서 살펴보시기 바랍니다.
도서출판 작은숲
[-- Attachment #2: Type: text/html, Size: 8497 bytes --]
^ permalink raw reply
* Re: MPC850 Pinout Description?
From: Leonardo Pereira Santos @ 2002-12-12 15:46 UTC (permalink / raw)
To: Donald MacArthur, linuxppc-embedded
In-Reply-To: <NDBBIHDFKLJKGJJGMFJOKEJACGAA.dmacarth@ufl.edu>
Well, I think the best document is the MPC850 manual, which is available as
a PDF file at Motorola's web site. Chapter 12 (External Signals) has
everything you need. Try this page
http://e-www.motorola.com/webapp/sps/library/documentationlist.jsp?rootNodeI
d=01&nodeId=018rH3bTdG8657&Device=MPC850&DocTypeKey=A0&Results=25
----- Original Message -----
From: "Donald MacArthur" <dmacarth@ufl.edu>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Thursday, December 12, 2002 11:57 AM
Subject: MPC850 Pinout Description?
>
> Does anyone know of a concise document which describes the pinouts and
> functions of the MPC850?
>
> Thank You
> Donald MacArthur
> dmacarth@ufl.edu
>
> Graduate Fellow
> Center for Intelligent Machines and Robotics
> Mechanical Engineering
> MEB300
> University of Florida
> Gainesville, Fla
> 32611
>
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Linux 2.5.51
From: Richard B. Johnson @ 2002-12-12 15:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: James Simmons, Benjamin Herrenschmidt, Stian Jordet, Allan Duncan,
linux-kernel
In-Reply-To: <m1isxzuvpi.fsf@frodo.biederman.org>
On 12 Dec 2002, Eric W. Biederman wrote:
> James Simmons <jsimmons@infradead.org> writes:
>
> > Unfortunely ATI doesn't like to release info on what needs to be done to
> > initialize without frimware. I really wish this was the case. I did see
> > email back about someone getting a mach64 card working without firmware.
> > They used a bus analysiser to do this. I will see what kind of patches I
> > can dig up.
>
> Thanks.
>
> Eric
The XFree people should know about this. Also, all the PCI/AGP
interface video boards, including those on motherboards, have
an internal BIOS that is sucked out of the board and written to
RAM at C0000 -> C8000 anyway. This stuff is visible from Linux
and can be disassembled by copying it to a file, then going to
VM86 mode DOS and disassembling with many kinds of real-mode DOS
tools. Since this is the real-mode BIOS that replaces the INT 0x10
default BIOS, all the function calls are known, and tracing what
registers they touch (and how) becomes a simple "time-sink".
Not hard, but just takes time.
Example of what's visible to Linux (this is an old Number 9 card).
000C0000 55 AA 40 E9 16 16 37 34-30 30 00 00 00 00 00 00 U.@...7400......
000C0010 00 00 00 00 00 00 00 00-10 02 00 00 00 00 49 42 ..............IB
000C0020 4D 20 56 47 41 20 43 6F-6D 70 61 74 69 62 6C 65 M VGA Compatible
000C0030 20 42 49 4F 53 2E 20 00-BB 66 F0 01 9F 01 F0 09 BIOS. ..f......
000C0040 09 FF 00 02 4E 75 6D 62-65 72 20 4E 69 6E 65 20 ....Number Nine
000C0050 56 69 73 75 61 6C 20 54-65 63 68 6E 6F 6C 6F 67 Visual Technolog
000C0060 79 20 20 20 20 20 20 20-20 20 20 39 46 58 20 4D y 9FX M
000C0070 6F 74 69 6F 6E 20 37 37-31 20 20 20 20 20 20 20 otion 771
000C0080 20 20 20 0E 20 4C 65 74-20 69 74 20 62 65 20 36 . Let it be 6
000C0090 38 2E 2E 2E 00 28 63 29-31 39 39 35 20 4E 75 6D 8....(c)1995 Num
000C00A0 62 65 72 20 4E 69 6E 65-20 56 69 73 75 61 6C 20 ber Nine Visual
000C00B0 54 65 63 68 6E 6F 6C 6F-67 79 20 43 6F 72 70 2E Technology Corp.
000C00C0 0D 0A 41 6C 6C 20 52 69-67 68 74 73 20 52 65 73 ..All Rights Res
000C00D0 65 72 76 65 64 0D 0A 00-23 39 2D 39 36 38 20 42 erved...#9-968 B
000C00E0 49 4F 53 20 56 65 72 73-69 6F 6E 20 32 2E 34 35 IOS Version 2.45
000C00F0 2E 31 35 0D 0A 00 28 63-29 31 39 39 35 20 53 33 .15...(c)1995 S3
The POST routine starts executing at offset 3. 0xaa55 is the signature,
the 0x40 byte is the number of 512-byte blocks to checksum (32,768 bytes),
and the initialization code follows. It just takes time. Everything you
need to know is in that 32,768 bytes.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Modules and dll
From: Alexandre Pires @ 2002-12-12 16:49 UTC (permalink / raw)
To: linux-kernel
Hi,
We could compare the modules programs of linux with dlls of Windows ?
Exist many differences between them (in relation to the functioning) ?
Thanks
Alexandre R. Pires
Brasil
_______________________________________________________________________
Busca Yahoo!
O melhor lugar para encontrar tudo o que você procura na Internet
http://br.busca.yahoo.com/
^ permalink raw reply
* Handling packets in userspace with libipq
From: Eduard Calvo (B-teljpa) EXP JAN 03 @ 2002-12-12 15:42 UTC (permalink / raw)
To: netfilter-devel
Hi gurus!
I have a brand new ip_queue handler to do SNAT before routing. It is located
in PREROUTING, and everything related to the caching of the packets and its
information seems to go right.
The problem arises when I have to return the NAT'ed packet to the next hook
with ip_set_verdict. I don't know quite well how to tell the kernel to get the
modifyed packet and not the copy it has.
In my code I have:
ret = ipq_set_verdict(qh, p->packet_id, NF_ACCEPT, (int)
ip_header->tot_len, p->payload);
And ret takes always -1.
Where: "p" is a ipq_message_t struct pointer that refers to the
modified packet read with ipq_read ant then ipq_get_packet.
"ip_header" is a iphdr struct pointer that starts in
p->payload.
Do you have any idea?
Thanks in advanced.
Eduard
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
^ permalink raw reply
* COUNTING in FORWARD.
From: Remigiusz Kosztowny @ 2002-12-12 15:38 UTC (permalink / raw)
To: linux-admin
Hello.
I have problem with 2.4.20 and 2.4.21-pre1
Counting in FORWARD rule don't work.
For example when i set:
iptables -N get-http
iptables -N put-http
iptables -I FORWARD -p tcp -o eth0 -s xx.xx.xx.0/24 --dport 80 -j put-http
iptables -I FORWARD -p tcp -o eth1 -d xx.xx.xx.0/24 --sport 80 -j get-http
This not work, because:
[root@bridge root]# iptables -xvnL FORWARD | head -n 3
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
0 0 get-http tcp -- * eth1 0.0.0.0/0
xx.xx.xx.0/24 tcp spt:80
0 0 put-http tcp -- * eth0 xx.xx.xx.0/24
0.0.0.0/0 tcp dpt:80
With 2.4.19 everything is OK.
I have bridge with 4 PC ethernet cards, iptables v1.2.7a
Please, help me.
--
Remigiusz Kosztowny
casper@IRCNet
PGP Key ID: 0x08495721 http://www.alfa-system.pl/~kacza/kacza.asc
[ When I Die, Bury Me Upside Down, So The Wolrd Can KISS MY ASS. ]
^ permalink raw reply
* Re: large await discrepancies
From: Joe Pruett @ 2002-12-12 15:30 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <Pine.LNX.4.44.0212100758160.29301-100000@q7.q7.com>
well, going to a different second controller didn't help any. immediately
i could see the second drive light going on and staying on for seconds at
a time with the system load going up to 30-40. so i have now broken the
mirror and things have been just fine since then. the highest load has
been maybe 5 since then. so obviously something is up with mirroring, or
that second drive. this is under stock redhat 7.2 with all patches. are
there known issues with mirroring in this release? i have a similar setup
at home, but running 7.1 and not under as heavy a load, but the iostat
numbers look just fine there.
^ permalink raw reply
* Re: Possible problem in asm/bitops.h
From: Tom Rini @ 2002-12-12 15:28 UTC (permalink / raw)
To: Georg Klug; +Cc: linuxppc-embedded
In-Reply-To: <FFECLICFNBJAHONLGAKMMEEJCHAA.gklug@giga-stream.de>
On Wed, Dec 11, 2002 at 04:31:14PM +0100, Georg Klug wrote:
> Q: Is the ffz() function desgined to work in a user space application, too? If
> yes, the file asm-ppc/bitops.h would need a change.
> Q: Does it make any sense to define one single macro (PPC405_ERR77()) in
> different
> ways in different include files?
The problem here is that userland programs are _not_ allowed to use
kernel headers, iirc, even programs which are tied to the kernel in some
way. They _must_ make a local copy of the include file which they
actually need. I suspect the actual problem is that iproute2 only needs
a very small amount of what is in include/linux/inetdev.h
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Success! TWO questions remain
From: Margaret Leber @ 2002-12-12 15:25 UTC (permalink / raw)
To: Hamish Moffatt; +Cc: linux-hams
In-Reply-To: <20021212132801.GA9699@silly.cloud.net.au>
Hamish Moffatt wrote:
> Compression is still hiding the data and I would say breaks the rules.
> Better solution: use SSH. You can have public key authentication (no
> cleartext passwords) without any encryption or compression.
Is encrypting even a password permitted outside of control of space
stations?
73 de Maggie K3XS
--
-----/___. _) Margaret Stephanie Leber / "The art of progress /
----/(, /| /| http://voicenet.com/~maggie / consists of preserving/
---/ / | / | _ _ _ ` _AOPA 925383/ order amid change and /
--/ ) / |/ |_(_(_(_/_(_/__(__(/_ FN20hd / change amid order." /
-/ (_/ ' K3XS .-/ .-/ ARRL 39280 /___ --A.N.Whitehead ___/
/____ICQ 7161096_(_/_(_/__AMSAT 32844____/ <maggie@voicenet.com>
^ permalink raw reply
* Re: DROP Fin Scan
From: Blizzards @ 2002-12-12 15:25 UTC (permalink / raw)
To: Dade; +Cc: netfilter
In-Reply-To: <1039703255.3df89cd74ff10@zigzag.cantine.org>
The idea behind the FIN scan, is not based on a NEW connection (only
pachet with the SYN bit set and ACK,RST,FIN cleared can initiate a new
connection), but in sending an RST/FIN to a server to probe ports.
Closed ports reply to this CLEAR CONNECT FIN bit set packet with a RST
bit set, while open port must ignore
the packet (this works on a unix TCP/IP stack).
FIN bits is sended by the client to server
server reply with ack
client close connect and reply with ack
server now send FIN and close connection
client receive final FIN and close all.
RST bit set produce an immediate closing of connection on both side.
In my opinion the 1st rule is exact:
iptables -A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
Bye.
G.
>:
>
>Hi,
>I'd like to block all FIN SCAN type. In Internet I find the following method:
>
>iptables -A INPUT -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
>
>but for me is better to write:
>
>iptables -A FORWARD -m state -state NEW -p tcp --tcp-flags FIN FIN -j DROP
>
>that means blocking all packets with flag FIN active regarding only packets
>belonging to new TCP connections.
>Are you agree?
>Thanks in advance,
>Davide
>
>
^ permalink raw reply
* [PATCH-2.5.50-ac1] Compaq Triflex IDE driver
From: Torben Mathiasen @ 2002-12-12 15:30 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 244 bytes --]
Hi,
Attached is a chipset driver for the Compaq Triflex IDE device
(PCI device ID 0xae33). Enables Busmaster DMA on both devices.
Known to work with the Compaq Workstation 5x00 series.
Let me know of any problems.
Thanks,
Torben Mathiasen
[-- Attachment #2: triflex-ide-2550ac1.diff --]
[-- Type: text/plain, Size: 10112 bytes --]
diff -urN -X exclude linux-2.5.50-ac1-clean/drivers/ide/Kconfig linux-2.5.50/drivers/ide/Kconfig
--- linux-2.5.50-ac1-clean/drivers/ide/Kconfig 2002-11-27 22:35:59.000000000 +0000
+++ linux-2.5.50/drivers/ide/Kconfig 2002-12-10 16:19:32.000000000 +0000
@@ -658,6 +658,12 @@
tristate "SLC90E66 chipset support"
depends on BLK_DEV_IDEDMA_PCI
+config BLK_DEV_TRIFLEX
+ tristate "Compaq Triflex IDE support"
+ depends on BLK_DEV_IDEDMA_PCI
+ help
+ This driver adds DMA support for the Compaq Triflex IDE device.
+
config BLK_DEV_TRM290
tristate "Tekram TRM290 chipset support"
depends on BLK_DEV_IDEDMA_PCI
diff -urN -X exclude linux-2.5.50-ac1-clean/drivers/ide/pci/Makefile linux-2.5.50/drivers/ide/pci/Makefile
--- linux-2.5.50-ac1-clean/drivers/ide/pci/Makefile 2002-11-27 22:35:51.000000000 +0000
+++ linux-2.5.50/drivers/ide/pci/Makefile 2002-12-11 11:54:09.000000000 +0000
@@ -29,6 +29,7 @@
obj-$(CONFIG_BLK_DEV_SLC90E66) += slc90e66.o
obj-$(CONFIG_BLK_DEV_TRM290) += trm290.o
obj-$(CONFIG_BLK_DEV_VIA82CXXX) += via82cxxx.o
+obj-$(CONFIG_BLK_DEV_TRIFLEX) += triflex.o
# Must appear at the end of the block
obj-$(CONFIG_BLK_DEV_GENERIC) += generic.o
diff -urN -X exclude linux-2.5.50-ac1-clean/drivers/ide/pci/triflex.c linux-2.5.50/drivers/ide/pci/triflex.c
--- linux-2.5.50-ac1-clean/drivers/ide/pci/triflex.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.5.50/drivers/ide/pci/triflex.c 2002-12-12 14:39:06.000000000 +0000
@@ -0,0 +1,249 @@
+/*
+ * triflex.c
+ *
+ * IDE Chipset driver for the Compaq TriFlex IDE controller.
+ *
+ * Known to work with the Compaq Workstation 5x00 series.
+ *
+ * Copyright (C) 2002 Hewlett-Packard Development Group, L.P.
+ * Author: Torben Mathiasen <torben.mathiasen@hp.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Loosely based on the piix & svwks drivers.
+ */
+
+#include <linux/config.h>
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/timer.h>
+#include <linux/mm.h>
+#include <linux/ioport.h>
+#include <linux/blkdev.h>
+#include <linux/hdreg.h>
+#include <linux/pci.h>
+#include <linux/ide.h>
+#include <linux/init.h>
+
+#include "ide_modes.h"
+#include "triflex.h"
+
+static struct pci_dev *triflex_dev;
+
+static int triflex_get_info(char *buf, char **addr, off_t offset, int count)
+{
+ char *p = buf;
+
+ struct pci_dev *dev = triflex_dev;
+ u32 bibma = pci_resource_start(dev, 4);
+ u8 c0 = 0, c1 = 0;
+ u32 pri_timing, sec_timing;
+
+ p += sprintf(p, "\n Compaq Triflex Chipset\n");
+
+ pci_read_config_dword(dev, 0x70, &pri_timing);
+ pci_read_config_dword(dev, 0x74, &sec_timing);
+
+ /*
+ * at that point bibma+0x2 et bibma+0xa are byte registers
+ * to investigate:
+ */
+ c0 = inb((unsigned short)bibma + 0x02);
+ c1 = inb((unsigned short)bibma + 0x0a);
+
+ p += sprintf(p, "--------------- Primary Channel "
+ "---------------- Secondary Channel "
+ "-------------\n");
+ p += sprintf(p, " %sabled "
+ " %sabled\n",
+ (c0&0x80) ? "dis" : " en",
+ (c1&0x80) ? "dis" : " en");
+ p += sprintf(p, "--------------- drive0 --------- drive1 "
+ "-------- drive0 ---------- drive1 ------\n");
+ p += sprintf(p, "DMA enabled: %s %s "
+ " %s %s\n",
+ (c0&0x20) ? "yes" : "no ",
+ (c0&0x40) ? "yes" : "no ",
+ (c1&0x20) ? "yes" : "no ",
+ (c1&0x40) ? "yes" : "no " );
+
+ p += sprintf(p, "DMA\n");
+ p += sprintf(p, "PIO\n");
+
+ return p-buf;
+}
+
+static int triflex_tune_chipset(ide_drive_t *drive, u8 xferspeed)
+{
+ ide_hwif_t *hwif = HWIF(drive);
+ struct pci_dev *dev = hwif->pci_dev;
+ u8 channel_offset = hwif->channel ? 0x74 : 0x70;
+ u16 timing = 0;
+ u32 triflex_timings = 0;
+ u8 unit = (drive->select.b.unit & 0x01);
+ u8 speed = ide_rate_filter(0, xferspeed);
+
+ pci_read_config_dword(dev, channel_offset, &triflex_timings);
+
+ switch(speed) {
+ case XFER_MW_DMA_2:
+ timing = 0x0103;
+ break;
+ case XFER_MW_DMA_1:
+ timing = 0x0203;
+ break;
+ case XFER_MW_DMA_0:
+ timing = 0x0808;
+ break;
+ case XFER_SW_DMA_2:
+ case XFER_SW_DMA_1:
+ case XFER_SW_DMA_0:
+ timing = 0x0f0f;
+ break;
+ case XFER_PIO_4:
+ timing = 0x0202;
+ break;
+ case XFER_PIO_3:
+ timing = 0x0204;
+ break;
+ case XFER_PIO_2:
+ timing = 0x0404;
+ break;
+ case XFER_PIO_1:
+ timing = 0x0508;
+ break;
+ case XFER_PIO_0:
+ timing = 0x0808;
+ break;
+ default:
+ return -1;
+ }
+
+ triflex_timings &= ~(0xFFFF << (16 * unit));
+ triflex_timings |= (timing << (16 * unit));
+
+ pci_write_config_dword(dev, channel_offset, triflex_timings);
+
+ return (ide_config_drive_speed(drive, speed));
+}
+
+static void triflex_tune_drive(ide_drive_t *drive, u8 pio)
+{
+ int use_pio = ide_get_best_pio_mode(drive, pio, 4, NULL);
+ (void) triflex_tune_chipset(drive, (XFER_PIO_0 + use_pio));
+}
+
+static int triflex_config_drive_for_dma(ide_drive_t *drive)
+{
+ int speed = ide_dma_speed(drive, 0); /* No ultra speeds */
+
+ if (!speed) {
+ u8 pspeed = ide_get_best_pio_mode(drive, 255, 4, NULL);
+ speed = XFER_PIO_0 + pspeed;
+ }
+
+ (void) triflex_tune_chipset(drive, speed);
+ return ide_dma_enable(drive);
+}
+
+static int triflex_config_drive_xfer_rate(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = HWIF(drive);
+ struct hd_driveid *id = drive->id;
+
+ if (id && (id->capability & 1) && drive->autodma) {
+ if (hwif->ide_dma_bad_drive(drive))
+ goto tune_pio;
+ if (id->field_valid & 2) {
+ if ((id->dma_mword & hwif->mwdma_mask) ||
+ (id->dma_1word & hwif->swdma_mask)) {
+ if (!triflex_config_drive_for_dma(drive))
+ goto tune_pio;
+ }
+ } else
+ goto tune_pio;
+ } else {
+tune_pio:
+ hwif->tuneproc(drive, 255);
+ return hwif->ide_dma_off_quietly(drive);
+ }
+
+ return hwif->ide_dma_on(drive);
+}
+
+static void __init init_hwif_triflex(ide_hwif_t *hwif)
+{
+ hwif->tuneproc = &triflex_tune_drive;
+ hwif->speedproc = &triflex_tune_chipset;
+
+ hwif->atapi_dma = 1;
+ hwif->mwdma_mask = 0x07;
+ hwif->swdma_mask = 0x07;
+ hwif->ide_dma_check = &triflex_config_drive_xfer_rate;
+
+ if (!noautodma)
+ hwif->autodma = 1;
+ hwif->drives[0].autodma = hwif->autodma;
+ hwif->drives[1].autodma = hwif->autodma;
+}
+
+static unsigned int __init init_chipset_triflex(struct pci_dev *dev,
+ const char *name)
+{
+#ifdef CONFIG_PROC_FS
+ ide_pci_register_host_proc(&triflex_proc);
+#endif
+ return 0;
+}
+
+static int __devinit triflex_init_one(struct pci_dev *dev,
+ const struct pci_device_id *id)
+{
+ ide_pci_device_t *d = &triflex_devices[id->driver_data];
+ if (dev->device != d->device)
+ BUG();
+
+ ide_setup_pci_device(dev, d);
+ triflex_dev = dev;
+ MOD_INC_USE_COUNT;
+
+ return 0;
+}
+
+static struct pci_driver driver = {
+ .name = "TRIFLEX IDE",
+ .id_table = triflex_pci_tbl,
+ .probe = triflex_init_one,
+};
+
+static int triflex_ide_init(void)
+{
+ return ide_pci_register_driver(&driver);
+}
+
+static void triflex_ide_exit(void)
+{
+ ide_pci_unregister_driver(&driver);
+}
+
+module_init(triflex_ide_init);
+module_exit(triflex_ide_exit);
+
+MODULE_AUTHOR("Torben Mathiasen");
+MODULE_DESCRIPTION("PCI driver module for Compaq Triflex IDE");
+MODULE_LICENSE("GPL");
+
+
diff -urN -X exclude linux-2.5.50-ac1-clean/drivers/ide/pci/triflex.h linux-2.5.50/drivers/ide/pci/triflex.h
--- linux-2.5.50-ac1-clean/drivers/ide/pci/triflex.h 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.5.50/drivers/ide/pci/triflex.h 2002-12-12 14:54:02.000000000 +0000
@@ -0,0 +1,55 @@
+/*
+ * triflex.h
+ *
+ * Copyright (C) 2002 Hewlett-Packard Development Group, L.P.
+ * Author: Torben Mathiasen <torben.mathiasen@hp.com>
+ *
+ */
+#ifndef TRIFLEX_H
+#define TRIFLEX_H
+
+#include <linux/config.h>
+#include <linux/pci.h>
+#include <linux/ide.h>
+
+static unsigned int __devinit init_chipset_triflex(struct pci_dev *, const char *);
+static void init_hwif_triflex(ide_hwif_t *);
+static int triflex_get_info(char *, char **, off_t, int);
+
+static ide_pci_device_t triflex_devices[] __devinitdata = {
+ {
+ .vendor PCI_VENDOR_ID_COMPAQ,
+ .device PCI_DEVICE_ID_COMPAQ_TRIFLEX_IDE,
+ .name "TRIFLEX",
+ .init_chipset init_chipset_triflex,
+ .init_iops NULL,
+ .init_hwif init_hwif_triflex,
+ .channels 2,
+ .autodma AUTODMA,
+ .enablebits {{0x80, 0x01, 0x01}, {0x80, 0x02, 0x02}},
+ .bootable ON_BOARD,
+ .extra 0,
+ },{
+ .vendor 0,
+ .device 0,
+ .channels 0,
+ .bootable EOL,
+ }
+};
+
+#ifdef CONFIG_PROC_FS
+static ide_pci_host_proc_t triflex_proc __initdata = {
+ name: "triflex",
+ set: 1,
+ get_info: triflex_get_info,
+ parent: NULL,
+};
+#endif
+
+static struct pci_device_id triflex_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_TRIFLEX_IDE, PCI_ANY_ID,
+ PCI_ANY_ID, 0, 0, 0 },
+ { 0, },
+};
+
+#endif /* TRIFLEX_H */
diff -urN -X exclude linux-2.5.50-ac1-clean/include/linux/pci_ids.h linux-2.5.50/include/linux/pci_ids.h
--- linux-2.5.50-ac1-clean/include/linux/pci_ids.h 2002-12-12 14:48:51.000000000 +0000
+++ linux-2.5.50/include/linux/pci_ids.h 2002-12-12 13:50:54.000000000 +0000
@@ -136,6 +136,7 @@
#define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc
#define PCI_DEVICE_ID_COMPAQ_SMART2P 0xae10
#define PCI_DEVICE_ID_COMPAQ_NETEL100 0xae32
+#define PCI_DEVICE_ID_COMPAQ_TRIFLEX_IDE 0xae33
#define PCI_DEVICE_ID_COMPAQ_NETEL10 0xae34
#define PCI_DEVICE_ID_COMPAQ_NETFLEX3I 0xae35
#define PCI_DEVICE_ID_COMPAQ_NETEL100D 0xae40
^ permalink raw reply
* 2.4.19 ( try_to_swap_out) does not set page->mapping to NULL
From: Bourne @ 2002-12-13 3:29 UTC (permalink / raw)
To: linux-kernel
Hi all, A small piece of code in mm/vmscan.c kept me confused. Please
could some one explain this ?
File: mm/vmscan.c , try_to_swap_out()
....SNIP....
drop_pte: mm->rss--
UnlockPage(page);
---SNIP--
page_cache_release(page);
return freeable;
----SNIP----
if(page->mapping)
goto drop_pte;
What i can get is if page->mapping is NOT NULL , then do a
page_cache_release(). This boils down to __free_pages_ok(). Here the
code snippet is if(page->mapping) BUG();
So if try_to_swap_out wants to drop a page which can be brought in
always ( i.e , not dirty ), then what is the harm in setting it to NULL ?
TIA
Bourne
^ permalink raw reply
* Re: Filter by IP address problems
From: Damon Brinkley @ 2002-12-12 15:16 UTC (permalink / raw)
To: netfilter; +Cc: stewart.thompson, netfilter
In-Reply-To: <200212120939.29993.netfilter@newkirk.us>
On Thu, 2002-12-12 at 09:39, Joel Newkirk wrote:
> On Thursday 12 December 2002 09:13 am, Damon Brinkley wrote:
> > Thanks Stu but I'm still doing something wrong.
> >
> > Here's the rules I have now.
> >
> > ###############################
> >
> > echo 0 > /proc/sys/net/ipv4/ip_forward
> >
> > /sbin/modprobe iptable_nat
> > /sbin/modprobe ip_conntrack
> > /sbin/modprobe ip_conntrack_ftp
> >
> > /sbin/iptables -F
> > /sbin/iptables -t nat -F
> > /sbin/iptables -X
> > /sbin/iptables -t nat -X
> >
> > /sbin/iptables -P INPUT DROP
> > /sbin/iptables -P OUTPUT DROP
> > /sbin/iptables -P FORWARD DROP
> >
> > # INPUT CHAIN
> > # NONUSERS = 172.17.0.0/20
> > /sbin/iptables -A INPUT -s $NONUSERS -j ACCEPT
> >
> > # FORWARD CHAIN
> > /sbin/iptables -A FORWARD -s $NONUSERS -j ACCEPT
> >
> > # POSTROUTING
> > /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> >
> > echo 1 > /proc/sys/net/ipv4/ip_forward
> >
> > ######################################
> >
> > This should give my laptop, IP 172.17.0.244, complete access but I get
> > Request timed out when pinging www.yahoo.com
> >
> > Here's what I get when running iptables -nL
>
> You can also run "iptables -t nat -nL" to show the nat table chains. As
> with most iptables calls, if you don't specify it assumes filter table.
>
> anyway, make sure you are also doing:
> echo 1 > /proc/sys/net/ipv4/ip_dynaddr
> so that it will actually have (and maintain) the current IP address for
> masquerading.
>
> Finally, you are not allowing any return connection back to the laptop
> through the FORWARD chain. Try adding:
>
> /sbin/iptables -A FORWARD -d $NONUSERS -m state \
> --state ESTABLISHED -j ACCEPT
>
> and it should work for browsing. If you use "ESTABLISHED,RELATED"
> instead then it should be more reliable, since it will allow icmp
> traffic related to the browsing.
>
> Also, you are allowing the laptop to communicate to the firewall box
> local processes (INPUT) but not allowing anything back from it to the
> laptop (OUTPUT). If you need them to communicate with each other, apart
> from the firewall forwarding (separate issues) then you need to allow
> communications in OUTPUT that go to the laptop as well, either simply
> ACCEPTing appropriate traffic, or using a state rule as above in OUTPUT
> to allow local processes on the firewall box to reply, but not initiate
> connections to the laptop.
>
> I've never worked with ipchains, just iptables, but I gather that with
> ipchains it was necessary to allow traffic through INPUT in order to
> forward. (I've seen this a lot this past week :^) With iptables the
> packets hit prerouting then netfilter decides whether the packet is
> destined for the local box, or forwarding, and it goes to EITHER one or
> the other, but not both. INPUT and OUTPUT are for the local box itself,
> and don't have any affect at all on forwarding, SNAT/DNAT, etc.
>
> j
>
>
Thank you so much j. You cleared up a lot of things and I believe
things are working now.
Thanks
Damon
^ permalink raw reply
* Re: R_MIPS_26 etc.
From: Greg Lindahl @ 2002-12-12 15:14 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <ECEPLLMMNGHMFBLHCLMAOEDMDGAA.yaelgilad@myrealbox.com>
On Thu, Dec 12, 2002 at 09:07:27AM +0200, yaelgilad wrote:
> Looking in the assembly code of my driver, I see the following
> pattern repeating with every function call.
> 4ce4: 0c000000 jal 0
> 4ce4: R_MIPS_26 rx_wait_packet
> (R_MIPS_26 is sometimes replaces by a similar command)
jal takes a 26 bit address. R_MIPS_26 is the corresponding relocation.
-- greg
^ permalink raw reply
* no segv running under gdbserver, segv without
From: Mark Pilon @ 2002-12-12 15:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm trying to debug our apps running on a 405pm target --
when the app is interrupted w/ a ctrl/C it's supposed to
cleanup and quit gracefully, as it does under X86.
it's seg faulting.
when I run it under gdbserver it seems to behave correctly
and I can't catch the failure.
any suggestions?
Thanks,
Mark
--
Mark Pilon
Minolta-QMS
P.O. Box 37
325 Dawson County Road 227
Fallon, MT. 59326-0037
1-406-486-5539 (primary voice line)
1-406-853-0433 (cell)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RH 8.0 vs. RH7.3 driver issues
From: Harlan Jillson @ 2002-12-12 15:12 UTC (permalink / raw)
To: linux-kernel
hi all,
I just subscribed to the list, and am looking for some suggestions.
I have a device driver for a RS485 card that does microlan
communications between several devices. The driver was written a couple
of years ago using the 2.2 kernel in RH 6.1. It's was updated for 2.4
kernel when RH7.3 was released and has been working fine. RH8.0 is
apparently a different story, as there appears to be problems with
scheduled timeouts (polling intervals) and maybe some interrupt issues.
My question is are there any known problems ( RH kernel 2.4.18-3)? I
know I'm dealing the revamps in the scheduler and timer areas and then
there's the shift from gcc 2.96 to 3.2.
Thanks for any suggestions,
Harlan
^ permalink raw reply
* Re: fetchmail and smtp problem
From: Carl @ 2002-12-12 15:11 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <5.1.0.14.1.20021211110250.020d8d90@celine>
Haines,
If you are collecting ALL the mail in the mail box on the ISP server to go to a SINGLE mailbox on your local server
then you can force fetchmail to rewrite the new To: header sent to sendmail with the --smtpname switch on
the command line (or the relevant keyword in the fetchmailconf file). This doesn't explain how 127.0.0.1 got in
the To: header but will stop it from happening again.
Regards
Carl
--
At 11:09 11/12/2002 -0800, you wrote:
>Haines -- It is hard to diagnose anything from this bounce, without information about what the original message looked like. A ways down in the bounce report is this information:
>
>>Date: Tue, 10 Dec 2002 13:58:47 -0500
>>Message-Id: <200212101858.gBAIwl3h003184@hartford-hwp.com>
>>From: Haines Brown <brownh@hartford-hwp.com>
>>To: 127.0.0.1
>>Subject: test from lo 10 dec 13:58
>>Reply-to: brownh@hartford-hwp.com
>
>The first question you need to answer is -- how did 127.0.0.1 get into the "To:" header? Was it an addressing error on your part, or did something rewrite it to that value? I'd suggest you check the outbox of whatever program you used to send the message. If the "To: 127.0.0.1" line appears in your original, then it was just a typo and of no significance to your troubleshooting (that is, the reject is correct). If the original has a different To: line, then post a followup with the details -- what MUA, which system (hard disk) you were using, and what the original To: line said.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Problems with IRC code
From: Michael A. Nunes @ 2002-12-12 15:10 UTC (permalink / raw)
To: netfilter
Background: I currently do NOT build my kernel with any modules, as my linux
box is only used as a firewall/router. I have no need to be able to
dynamically load/unload parts of the kernel. Therefore, I build all
netfilter code directly into my kernel.
Problem: Up until 2.4.20 it has always been possible for me to hard-code
ports into ip_conntrack_irc.c and ip_nat_irc.c by simply adding the
following:
if (ports[0] == 0) {
ports[0] = 4646;
ports[1] = 5190;
ports[2] = 5554;
ports[3] = 6667;
ports[4] = 6868;
ports[5] = 7000;
in the respect parts of either file. Like I said, this has ALWAYS worked up
until 2.4.20. DCCs in/out on any ports in the above list would always work.
With 2.4.20 after adding the above the only thing that works is DCCs IN!
DCCs going out from a NAT'd box no longer make it through!
Question: What in the IRC code has changed so drastically that
I can no longer use the above method for "hard-coding" ports?
--
Michael A. Nunes
/p at pcmike dot net
http://pcmike.net/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.