Linux-Development-Sys Digest #406, Volume #8 Wed, 10 Jan 01 22:13:13 EST
Contents:
Re: Extending /proc filesystem on Solaris 7/8? (Casper H.S. Dik - Network Security
Engineer)
Re: kernel 2.4.0 + RAID causes problems ("Oliver Kowalke")
Kernel -> user mode data tranfer ???? (byteme)
Re: UNIX98 Pty's ???? ("Karl Heyes")
Routing and rtnetlink ([EMAIL PROTECTED])
Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel. (Jerry Peters)
Re: Extending /proc filesystem on Solaris 7/8? ("Peter T. Breuer")
Re: Problems with MINORS in Device Driver Writing
Re: 2.2.18 won't boot diskless
Re: VFAT problems with Kernel 2.2.18 ("Steff Donachie")
Re: Extending /proc filesystem on Solaris 7/8? (Kaelin Colclasure)
Re: device driver dev ([EMAIL PROTECTED])
Re: Maturity of Bonobo and CORBA (Kaelin Colclasure)
The magic address 0x8048000 (Zhihui Zhang)
Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel. ("Gene Heskett")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 10 Jan 2001 21:28:15 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
Kaelin Colclasure <[EMAIL PROTECTED]> writes:
>What we've seen going on in the networking world for the past few decades
>is that text-based protocols survive and evolve, while binary ones tend
>not to fare well. At a recent IETF WG meeting I attended, this point
>was raised and generated quite a bit of contention -- but when examples
>had been enumerated, I for one was pretty convinced. Now certainly a
>poorly designed protocol is not going to flourish wether text-based or
>binary, but the weight of evidence in the Internet protocol arena
>strongly suggests that there are real advantages to adopting a textual
>representation.
I don't think this argument really applies here. While I avoid Linux, I can't
remeber having seen versioning information in the /proc entries or
code numbers that allow for extension of the data stream. Just adding a
field will not work in some parse methods.
Protocols survive when they are extensible; SMTP and FTP and perhaps
HTTP would be an example (though HTTP is a poor example of a protocol
anyway) of text based protocols, but telnet is very binary and has
also survived. Many extensions for telnet have been proposed and
implemented, including encryption and other forms of authentication.
Rlogin/rsh/rexec where poorly defined protocols and had to be replaced
(hence krlogin/ssh etc) It was simply not possible to extend them.
We've gone through some hoops to even get ACLs into rcp.
Other binary protocols hat have survived well are X11, Sun RPC.
X because its extensible, Sun RPC because it's flexible, forces
versioning and requires strong parsing of protocol packets
(sloppiness is not tolerated). X11 also does a lot of error checking.
So what favours a protocol, is it text or binary? I think it's
how well it's defined, how extensible it is and how well the majority
of implementations refuses to deal with bad implementations.
Microsoft's first SMTP implementation was fortunately not very
popular when SMTP started to move forward again. It would drop
connection on "EHLO"; I think this was then worked around by reconnecting
w/o extensions, but it certainly made going forward harder.
The same goes for extensibility of the API/ABI. Is there room for
extention (spare flag bits, undefined values)? Are you doing
proper error checking? Improper checking for errors is a bad problem;
when you extend an interface old (broken) programs may suddenly stop
to function.
>Also, what little I have read on Plan 9 suggests that they have taken
>the Unix-is-file-descriptors-and-text concept to new extremes. I'm
>sure I read in some article or other that Plan 9 dumped ioctl in favor
>of having "command strings" written to the device fds. And I would
>submit to you that the folks who put together Plan 9 knew a thing or
>two about Unix, its history, what's worked and what's not over the
>years...
But I think they also realized that such an approach would have
made the original Unix kernels large and slow text parsers.
It's just that the idea of converting things into text *inside the kernel*
only to be reconverted back most of the time is abhorrant.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
From: "Oliver Kowalke" <[EMAIL PROTECTED]>
Subject: Re: kernel 2.4.0 + RAID causes problems
Date: Wed, 10 Jan 2001 22:55:52 +0100
I solved my problem by excluding devfs-driver from the kernel - setting
devfs = nomount as boot param should also work.
cu,
Oliver
------------------------------
From: [EMAIL PROTECTED] (byteme)
Subject: Kernel -> user mode data tranfer ????
Date: Wed, 10 Jan 2001 22:39:19 GMT
Looking for some suggestions on the best way to transfer a char string
form a module to an awaiting user space proccess.
The module should initiate the the communications.
1) Use put_user & then send the proc a SIG
2) Use AF_UNIX Socket with the proc listening on a port
3) Implement a Call Back function in the user proc. that the module
can call.
I've never had to do this where the module init's the COMM. any
ideas out there
thanx in advance
kevin
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: UNIX98 Pty's ????
Date: Wed, 10 Jan 2001 22:54:07 +0000
In article <[EMAIL PROTECTED]>, "Eric" <[EMAIL PROTECTED]>
wrote:
> Morten B�hmer wrote:
>>
>> What should the inittab look like?
>>
>
> I presume you mean the fstab.
>
> none /dev/pts devpts
> gid=5,mode=620
>
> 0 0
Just for completness, like proc don't use none, use devpts, it doesn't
do anything in itself but if any errors come up then it won't
identify the filesystem as none.
karl.
------------------------------
From: [EMAIL PROTECTED]
Subject: Routing and rtnetlink
Date: Wed, 10 Jan 2001 22:45:25 GMT
I'm using Red Hat 6.2 with the 2.2.14 kernel.
Is there a way to dump the entire routing table (displayed when you type
"ip route") to an application using rtnetlink? I've looked at the man
pages for it, and didn't see anything that looked like it would work.
Any help is greatly appreciated.
Thanks,
Dave
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel.
Date: Wed, 10 Jan 2001 23:47:17 GMT
Gene Heskett <[EMAIL PROTECTED]> wrote:
> Gene Heskett sends Greetings to Dave ;
>> Problem: Unable to connect to I.S.P. (LCP timeout sending config
>> requests) after kernel upgrade (2.2.13 to 2.4.0)
>> I'm running a SuSE 6.3 system with a 2.2.13 kernel, ppp 2.3.10, kppp
>> 1.6.23, Netscape-6 (bloatware) and Helix-Gnome. Dialing my isp (USR
>> 5686-03
>> 56K serial on /dev/ttys1) everything is fine and happy and has been
>> for some time.
>> I installed a 2.4 kernel. Everything seems fine during boot; gdm
>> starts no problem, but ppp (still 2.3.10) dies when I try to dial
>> the I.S.P. using kppp. Following is the log:
>> -- pppd 2.3.10 started by root, uid0
>> -- using interface ppp0
>> -- connect ppp0 <--> /dev/ttys1
>> -- sent [LCP ConfReq id=0x1 <asyncmap 0x0><magic
>> 07049e221><pcomp><accomp>
>> ... 30 seconds goes by ...
>> -- LCP: timeout sending Config-requests.
>> I can shut down and restart using the 2.2.13 kernel (on the same
>> system; two boot images), and dial up/use the ISP just fine (is how
>> I posted this message).
>> I Searched/GOOGLE-ed the net, lots of hits on LCP timeouts, no luck
>> why this happens going 2.2.13 --> 2.4.0, *or*, how to fix things.
>> Question is: anyone seen this and know how to fix it? I'd sure
>> appreciate the help.
> Well, there have been prolly 20 messages pointed at me with the same
> problem. They *all* say RTFM in the 2.4.0 tree. Theres lot of info there
> about how to setup a ppp dialin lashup, meaning to be able to dial into
> your machine from elsewhere. The man pages that *should* be in the rpm?
> fugetaboudit, they haven't been touched in ages and are for the most
> part irrevalent.
> Unforch, there is an absolute minimum of info on what actually was
> changed that effects your basic 'call your ISP' functions. I've rebuilt
> it from the tar.gz 2 or 3 times now, but when its installed and
> rebooted, the error messages say its looking for chap-secrets in some
> directory that doesn't exist on my system,
> '/etc/networks/network-scripts' or some such. And here I thought all
> the ppp option files were in /etc/ppp.
> I'd like to see a really valid explanation as to why the man pages
> aren't being maintained, but in most cases only the html versions.
> While they are pretty, they aren't worth the disk space on the vendors
> server or mine if I first have to get x working, followed by a decent
> browser just so information that *should* be in the man pages and
> accessable from any cli can be viewed.
> By damn I finally got it! kernel 2.4.0 and ppp-2.4.1 works!
> I detest shouting as much as the rest but...
> THE SECRET, AND NO PLACE IN THE DOCS THAT I'VE SPENT A FSCKING MONTH
> RE-READING, DOES IT TELL YOU TO MOVE YOUR /etc/ppp/*-secrets FILES TO
> /etc/sysconf/network-scripts/*-secrets!
> Find a *large* block of soft stone, it only has to last till 2.4.0-ac5
> probably, carve the above message in it, and throw it forcefully at the
> next 10,000 people that ask this question.
> Only the error messages contained in the debug log for ppp show that
> missing file error.
> Like I said, repeatedly, the man pages SUCK!
> Cheers, Gene
> --
> Gene Heskett, CET, UHK |Amiga A2k Zeus040, Linux @ 600mhz
> email gene underscore heskett at iolinc dot net
> #Amiga based X10 home automation program EZHome, see at:#
> # <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
> ISP's please take note: My spam control policy is explicit!
> #Any Class C address# involved in spamming me is added to my killfile
> never to be seen again. Message will be automaticly deleted without dl.
> This messages reply content, but not any previously quoted material,
> is � 2000 by Gene Heskett, all rights reserved.
> --
Definitely not my pppd, which came from cs.anu.edu.au. It expects
everything in /etc/ppp. I would suspect a distribution customized
pppd. If the distro has changed the location of the config files, then
the distro should have changed the man pages accordingly.
I use Slackware, what are you using Redhat?
Jerry
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: Thu, 11 Jan 2001 00:47:21 +0100
In comp.os.linux.development.system Casper H.S. Dik - Network Security Engineer
<[EMAIL PROTECTED]> wrote:
> I don't think this argument really applies here. While I avoid Linux, I can't
> remeber having seen versioning information in the /proc entries or
> code numbers that allow for extension of the data stream. Just adding a
> field will not work in some parse methods.
On the contrary, it works fine. What could be simpler?
file = { ws* name ws* ':' ws* value ws* '\n' }*
and there you are.
Peter
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Problems with MINORS in Device Driver Writing
Date: Thu, 11 Jan 2001 00:36:16 -0000
In article <93i0kv$u5f$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>Thanks for the reply Ninja, but yes I have tried the Minor macro but
>somehow, it returns a 0 every time. Like I said, its like the inode
>structure from the OS is coming back empty.
Maybe this is what you are wanting:
MINOR(file->f_dentry->d_inode->i_rdev)
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: 2.2.18 won't boot diskless
Date: Thu, 11 Jan 2001 00:39:18 -0000
In article <93fkgc$pua$[EMAIL PROTECTED]>,
Tom Daley <[EMAIL PROTECTED]> wrote:
>Yes, the network support is NOT a module.
Is the NIC driver a module?
--
http://www.spinics.net/linux
------------------------------
From: "Steff Donachie" <[EMAIL PROTECTED]>
Subject: Re: VFAT problems with Kernel 2.2.18
Date: Thu, 11 Jan 2001 01:33:55 -0000
"Keith Hulse" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi, I am relatively new to Linux and I have a problem after compiling the
> new 2.2.18 kernel. My floppy, zip, and Windows drives (yes I am running
> Win98 as well!) are not mounted. The message I get is along the lines of:
> These file systems are not supported by 2.2.18.
>
> The kernel is compiling autofs and using it but I don't know where to go
> next. Can anyone help.
>
> Keith Hulse
>
> --
> Posted via CNET Help.com
> http://www.help.com/
I suspect you haven't compiled support for these filesystems into the
kernel:-Did you do a make config/xconfig/menuconfig first ?
Look for supported filesystems-VFAT,FAT
cheers
Steff
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 10 Jan 2001 17:46:19 -0800
[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
> Kaelin Colclasure <[EMAIL PROTECTED]> writes:
>
> >What we've seen going on in the networking world for the past few decades
> >is that text-based protocols survive and evolve, while binary ones tend
> >not to fare well. At a recent IETF WG meeting I attended, this point
> >was raised and generated quite a bit of contention -- but when examples
> >had been enumerated, I for one was pretty convinced. Now certainly a
> >poorly designed protocol is not going to flourish wether text-based or
> >binary, but the weight of evidence in the Internet protocol arena
> >strongly suggests that there are real advantages to adopting a textual
> >representation.
>
> I don't think this argument really applies here. While I avoid Linux, I can't
> remeber having seen versioning information in the /proc entries or
> code numbers that allow for extension of the data stream. Just adding a
> field will not work in some parse methods.
This is true -- but the same criticism applies to the binary contents
of the Solaris /proc entries, does it not? You may argue that application
programs should be linking to libraries instead of reading directly from
/proc, and I would agree with you. But how much of /proc is accessible
that way today? (Not a rhetorical question -- I honestly don't know.)
[...]
> The same goes for extensibility of the API/ABI. Is there room for
> extention (spare flag bits, undefined values)? Are you doing
> proper error checking? Improper checking for errors is a bad problem;
> when you extend an interface old (broken) programs may suddenly stop
> to function.
Yes, of course -- engineering for the future is hard. This applies
equally to Internet protocols and API's. I don't think anyone who has
attempted either would argue...
> >Also, what little I have read on Plan 9 suggests that they have taken
> >the Unix-is-file-descriptors-and-text concept to new extremes. I'm
> >sure I read in some article or other that Plan 9 dumped ioctl in favor
> >of having "command strings" written to the device fds. And I would
> >submit to you that the folks who put together Plan 9 knew a thing or
> >two about Unix, its history, what's worked and what's not over the
> >years...
>
> But I think they also realized that such an approach would have
> made the original Unix kernels large and slow text parsers.
>
> It's just that the idea of converting things into text *inside the kernel*
> only to be reconverted back most of the time is abhorrant.
Aha, it comes to the age-old "efficiency" argument! I'll leave my
rebuttal at that... ;-)
-- Kaelin
------------------------------
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: Re: device driver dev
Date: Thu, 11 Jan 2001 02:08:55 GMT
>>>>> "ellis" == <[EMAIL PROTECTED]> writes:
ellis> In article <[EMAIL PROTECTED]>, Ionel GARDAIS
ellis> <[EMAIL PROTECTED]> wrote:
>> I think i'm a good coder in C but I have never progam for Linux
>> yet.
>> It might take a while before I engage the driver coding. (I plan to
>> buy a kind of O'Reilly book to learn basic device programming).
ellis> What you need for a print isn't really a driver; it's just a
ellis> filter and is done is user space. You can get the basic idea
ellis> from the gimp-print source.
Indeed. There's "stuff you do in the kernel," and "stuff you do in
user space;" this is a place where the division is reasonably clear.
Interfacing to printer _hardware_ generally amounts to having an
interface that knows how to pump a bunch of bytes across the
appropriate set of wires.
And so, from Linux's perspective, the "printer driver" is generally
just the bit of code that knows how to throw bytes at the parallel
port.
The question of exactly what bytes to throw at the port is a separate
question, and does not really need to sit in 'kernel space.'
<http://www.uwsg.indiana.edu/hypermail/linux/kernel/0005.3/0061.html>
has a very useful quote to this end:
"The kernel is the thing that translates physical I/O to logical
I/O. Attempting to perform logical I/O in the kernel is
effectively going backwards."
That's specifically directed at answering those people that _think_
they need to have the kernel open and read files; the point in the
first sentence is one that needs to be thrown at anyone that thinks
they want to do oddball things in the kernel.
Think hard about what it is that you want to do:
- Are you trying to do physical I/O? If so, then that's the _perfect_
thing to do in the kernel.
- Are you trying to do logical I/O, like reading files, or
transferring a bunch of data, or translating data? If so, then
that's very likely the _wrong_ thing to do in the kernel.
There's some ambiguity in between those extremes; in such cases, there
_needs_ to be a heated debate to determine what belongs where.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
There are few personal problems which can't be solved by the suitable
application of high explosives.
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: Maturity of Bonobo and CORBA
Date: 10 Jan 2001 18:30:10 -0800
"Edgar F. Hilton" <[EMAIL PROTECTED]> writes:
[...]
> > > I am interested in writing some applications in Linux that heavily rely
> > > on CORBA. Does anybody know how well CORBA and Bonobo work in Linux?
> > > Any caveats that I should be aware of? My applications are intended
> > > to work in an Enterprise environment, so any comments that are relevant
> > > on the subject would be much appreciated so that I may retain my job...
> > > ;)
If you're writing applications for an Enterprise environment, are you
constrained to only free CORBA implementations? If not, I recommend
taking a close look at Orbacus <http://www.ooc.com/>. It's a very
feature complete, well supported commercial implementation distributed
with full source code. And the licensing terms and fees are *very*
reasonable.
-- Kaelin
------------------------------
Date: Wed, 10 Jan 2001 21:42:03 -0500
From: Zhihui Zhang <[EMAIL PROTECTED]>
Subject: The magic address 0x8048000
The code of a process seems to start from some place around 0x800,0000.
Why it does not start from virtual address 0? Is there a way to achieve
this? Thanks for your help.
-Zhihui
------------------------------
Date: 10 Jan 2001 21:7:37 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel.
Gene Heskett sends Greetings to Jerry Peters;
JP> Gene Heskett <[EMAIL PROTECTED]> wrote:
[...]
>> By damn I finally got it! kernel 2.4.0 and ppp-2.4.1 works!
>> I detest shouting as much as the rest but...
>> THE SECRET, AND NO PLACE IN THE DOCS THAT I'VE SPENT A FSCKING
>> MONTH RE-READING, DOES IT TELL YOU TO MOVE YOUR /etc/ppp/*-secrets
>> FILES TO
>> /etc/sysconf/network-scripts/*-secrets!
>> Find a *large* block of soft stone, it only has to last till
>> 2.4.0-ac5 probably, carve the above message in it, and throw it
>> forcefully at the next 10,000 people that ask this question.
>> Only the error messages contained in the debug log for ppp show
>> that missing file error.
>> Like I said, repeatedly, the man pages SUCK!
>> Cheers, Gene
>> --
>> Gene Heskett, CET, UHK |Amiga A2k Zeus040, Linux @ 600mhz
>> email gene underscore heskett at iolinc dot net
>> #Amiga based X10 home automation program EZHome, see at:#
>> # <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
>> ISP's please take note: My spam control policy is explicit!
>> #Any Class C address# involved in spamming me is added to my
>> killfile never to be seen again. Message will be automaticly
>> deleted without dl. This messages reply content, but not any
>> previously quoted material, is � 2000 by Gene Heskett, all rights
>> reserved.
>> --
JP> Definitely not my pppd, which came from cs.anu.edu.au. It expects
JP> everything in /etc/ppp. I would suspect a distribution customized
JP> pppd. If the distro has changed the location of the config files,
JP> then the distro should have changed the man pages accordingly.
Jerry, I'd *almost* argue that point, because I'm quite sure I got that
tar.gz from the .au site Clifford Kite gave me a few weeks back. Of
course .au is a heck of a lot of square miles, so it might not have been
the same site, but it most certainly was an aussie site I got it from.
Is that the same site you gave me Clifford?
JP> I use Slackware, what are you using Redhat?
More or less, but this wasn't from an rpm. I have one of those too, but
the rpm destroys my configuration totally, so after 3 passes at making
it work, and spending about half an hour recovering my configs from each
attempt, I finally gave up. It felt so good when I quit beating my head
on the wall... :-)
I'm less and less impressed with RH these days, with a few security
patches, 6.2 was their best distro by far. I only updated because all
of a sudden everything I downloaded was built needing GLIBC-2.2 and/or
rpm-4.0 or better. In case RH is reading the mail here, I do not
subscribe to the planned obsolescence theory, I'd much rather subscribe
to the 'if its not broke, don't fix it' theory.
Cheers, Gene
--
Gene Heskett, CET, UHK |Amiga A2k Zeus040, Linux @ 600mhz
email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
# <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
ISP's please take note: My spam control policy is explicit!
#Any Class C address# involved in spamming me is added to my killfile
never to be seen again. Message will be automaticly deleted without dl.
This messages reply content, but not any previously quoted material,
is � 2000 by Gene Heskett, all rights reserved.
--
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
