You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1998/02/02 20:47:18 UTC
Re: apache/linux modules
At 02:23 PM 2/2/98 -0500, Cristian Gafton wrote:
>Would you be interested in some patches to make apache 1.3 compile its
>modules as shared libraries and load them on startup ?
>
>I find this method that apche should be recompiled every time you add a
>module very frustrating. i have done some patches that will allow modules
>to be compiled as shared libraries (.so files), and apache will dlopen()
>them on startup, loadin all modules present in a certain directory
>(/usr/lib/apache for example)
There is definitely some interest in doing that, but we are trying to close
up 1.3 so I don't know if it can make it in. I would advocate you (or
someone) from redhat join the developer's list (majordomo@apache.org,
subscribe new-httpd, they're also cc'd on this response) and present the
patches. I know there's at least one other shared-library patch out there.
I'd be interested, personally speaking, in seeing it work before 1.3
final, but the group seems to be moving towards closure so we can move to
2.0.
>Also, are you aware of any work in progress to make apache 1.3 use the GNU
>autoconf program (lower priority, but still doable and cool)
We've had rancorous discussions about whether it's a good idea; basically
boiling down to concerns that autoconf would not be easy to extend if there
was suddenly an issue (such as the whole serialized-accept bizness) which
we needed to address per platform. If you have experience with this and
want to address the concerns a few members of the group have about it, it's
definitely a possibility we'd consider.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> *But* since I expect autoconf would eliminate the rather annoying porting
> bug reports we get I'm mostly for it. I just don't want to --have --to
> --specify --sixteen --million --command --line --options --when --building
> --a --static --server.
I completely agree. The basic ./configure command should do what now the
./Configure script does. If you want fancy features, be prepared to
--give --fifty-thousand --command --line arguments. I don't much care how
many they are, I just want to have the options. For a distribution maker
that means sticking the parameters into a spec file for the package and
rebuilding from that point without having to worry about porting
distribution-specific patches to new code bases.
So I am not suggestinga complicated way to do simple things... All the new
users should note is the difference in spelling between ./Configure and
./configure - nothing more.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Brian Behlendorf wrote:
>
> > was suddenly an issue (such as the whole serialized-accept bizness) which
> > we needed to address per platform. If you have experience with this and
>
> As long as you can build a test case in what you are interested, the
> autoconf will handle it...
That's the problem, you can't necessarily build a test case. As I
mentioned there are some bugs which show up only under heavy load, or only
when there are slow remote clients, and so on. These are insidious kernel
bugs that we have to work around.
There are things like serializing primitives -- we have a half dozen ways
of doing it. In order to decide which of many to use on a particular
system we generally do some benchmarking. But it turns out that some
systems vary greatly depending on what options are installed, or if the
box is SMP or UP (IRIX comes to mind). So we default to something that's
the least broken. But that default is different for different
platforms...
So in the end I fear we'd end up using autoconf in a way it wasn't meant
to be used -- with dozens of architecture specific hacks.
*But* since I expect autoconf would eliminate the rather annoying porting
bug reports we get I'm mostly for it. I just don't want to --have --to
--specify --sixteen --million --command --line --options --when --building
--a --static --server.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Brian Behlendorf wrote:
> There is definitely some interest in doing that, but we are trying to close
> up 1.3 so I don't know if it can make it in. I would advocate you (or
> someone) from redhat join the developer's list (majordomo@apache.org,
> subscribe new-httpd, they're also cc'd on this response) and present the
> patches.
I subscribed to the list, thanks. I will try to catch up about past
discussions on the list from the archives (if there are any - still
waiting for majordomo's response) then I'll jump into the fire... :-)
The modifications to the module handling problem are quite simple:
- we build modules as shared libraries
- the apache server will start dlopen()-ing all the mod-XXX.so
files found in a certain directory on startup and resolve the module entry
structure using dlsym()
- after all the modules are loaded we build the
prelinked_modules and preloaded_modules arrays (used to be built by
Configure in modules.c)
- everything will proceed normally from that point on.
Optionally, we can have the modules named mod-XXX.so.1.2.5 with a link
named mod-XXX.so to them. This way, if we need to stop apache from loading
a module we remove the .so link from the modules directory
(eg /usr/lib/apache)
I have a patch for 1.2.5 and I am trying to adapt it to 1.3 series.
> was suddenly an issue (such as the whole serialized-accept bizness) which
> we needed to address per platform. If you have experience with this and
As long as you can build a test case in what you are interested, the
autoconf will handle it...
Thanks for your time,
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Ben Laurie <be...@algroup.co.uk>.
Cristian Gafton wrote:
>
> On Mon, 2 Feb 1998, Ben Laurie wrote:
>
> > No. This is a really cool way to make sure that you never get the same
> > build of Apache twice (or any other autoconfed package). This is one
>
> You're giving autoconf too much credit :-) Like the ability to generate
> different results on two identical runs... It can not do that... Yet. :-)
No, but it encourages you to not do identical runs.
> > "feature" of autoconf that drives me completely crazy. Try sharing
> > sysadmin on a machine in the face of this kind of stuff going on.
>
> $ echo "exec ./configure --my-options" > build.apache
> $ chmod 755 build.apache
> $ mail -s "how to build apache" otherguy
> Enter "." on a line to end
>
> Hey, use the build.apache script to build apache for our servers,
> will ya ?
>
> Your cool colleague,
> .
> $
>
> Isn't that cool ?
Yes. So cool we built into the distribution and called it
"Configuration".
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: apache/linux modules
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> But with 2.0, sure. We should just start with an empty repository, agree
> to use autoconf correctly, and populate things as they become necessary.
> (Hi Roy!)
I think for 2.0, we should go a step beyond autoconf. Go right to
automake/libtool which sit on top of autoconf in order to provide a proper
framework for building shared libs on all platforms.
-Rasmus
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> The same exact type of overriding and special test cases you can do with
> autoconf too. In this respect there is no difference. I did not say that
> autoconf will save you in cases like this. I said that it will simplify
> other tests and lists of features for each platform.
Yup, this is what I said in my first message about autoconf this morning.
I know autoconf supports hacks like this. My point was that Apache and
autoconf use a different architecture naming method, and so moving from
one to the other is going to be a painful process.
It's debatable whether it's easier with autoconf or with Configure... what
I do know is that Configure works well enough right now that I'm not
overly keen on breaking everything soon.
But with 2.0, sure. We should just start with an empty repository, agree
to use autoconf correctly, and populate things as they become necessary.
(Hi Roy!)
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> as simple as that. For example, the following POSIX program fragment
> fails on many svr4 systems:
[...]
autoconf can not do this for you. Neither the current ./Configure. You
have hard-coded this stuff into ./Configure and ./Configure will act
accordingly.
The same exact type of overriding and special test cases you can do with
autoconf too. In this respect there is no difference. I did not say that
autoconf will save you in cases like this. I said that it will simplify
other tests and lists of features for each platform.
> I'm not aware of any other server which uses the same model as Apache.
> I'd love to be told of one though, so that we can go look and compare
> our solutions.
Sorry, I am not aware of any program that does this.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
>
> > Sure. How does it differ from "./Configure ; make"?
> >
> > I still have grave concerns about autoconf's ability to sense all the
> > platform-specific issues src/Configure does.
>
> Well, it does so for squid. And for gcc. And for emacs. And for
> PostgreSQL. And for sendmail. And for bind. And for a whole plethora of
> big, large programs with heavy requirements on identifying the exact
> differences between platforms.
>
> Why wouldn't it do it for apache ?!
Because apache uses multiple co-operating processes that require
lightweight IPC and require shared network sockets. In many cases it's
as simple as that. For example, the following POSIX program fragment
fails on many svr4 systems:
{
int s;
int i;
.... set up s for listening ....
/* fork two children */
for (i = 0; i < 2; ++i) {
if (fork() == 0) {
int client = accept(s);
...
}
}
}
Many systems just don't like having multiple processes doing accept()
on the same socket. But they don't tell you that directly, they may
not even tell you with this example. They may only tell you that they
suck when you've got 50 children all busy serving requests. And the
system will tell you it sucks by melting the CPU or maybe panicing.
But in no way will it tell you with an errno from accept() or other
useful thing you can automatically test.
None of the programs you list above are like Apache. Even squid is
different -- it is a single monolithic process. sendmail uses multiple
processes, but there is only one main process doing accept(), and there's
almost no (lightweight) IPC.
I'm not aware of any other server which uses the same model as Apache.
I'd love to be told of one though, so that we can go look and compare
our solutions.
There are certainly bugs that we can test, like the hack in make_socket()
that deals with TCP/streams lameness on solaris and other svr4 boxes
regarding SO_REUSEADDR. I'm not denying this. I'm just saying there
are bugs which aren't easy to test.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> Sure. How does it differ from "./Configure ; make"?
>
> I still have grave concerns about autoconf's ability to sense all the
> platform-specific issues src/Configure does.
Well, it does so for squid. And for gcc. And for emacs. And for
PostgreSQL. And for sendmail. And for bind. And for a whole plethora of
big, large programs with heavy requirements on identifying the exact
differences between platforms.
Why wouldn't it do it for apache ?!
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Cristian Gafton wrote:
>
> $ echo "exec ./configure --my-options" > build.apache
> $ chmod 755 build.apache
> $ mail -s "how to build apache" otherguy
:
> Isn't that cool ?
Sure. How does it differ from "./Configure ; make"?
I still have grave concerns about autoconf's ability to sense all the
platform-specific issues src/Configure does.
#ken P-)}
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Ben Laurie wrote:
> No. This is a really cool way to make sure that you never get the same
> build of Apache twice (or any other autoconfed package). This is one
You're giving autoconf too much credit :-) Like the ability to generate
different results on two identical runs... It can not do that... Yet. :-)
> "feature" of autoconf that drives me completely crazy. Try sharing
> sysadmin on a machine in the face of this kind of stuff going on.
$ echo "exec ./configure --my-options" > build.apache
$ chmod 755 build.apache
$ mail -s "how to build apache" otherguy
Enter "." on a line to end
Hey, use the build.apache script to build apache for our servers,
will ya ?
Your cool colleague,
.
$
Isn't that cool ?
:-)
Best wishes,
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Ben Laurie <be...@algroup.co.uk>.
Cristian Gafton wrote:
>
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > If it's an issue of apache 1.2 and -lcrypt on redhat 5.0... that's fixed
> > in 1.3 already (and can't easily be fixed in 1.2 without adding a lot of
> > features). What other issues with 1.3 are there that would require
> > autoconf?
>
> It's not only the -lcrypt issue. What about the ability to configure your
> software without having to edit some configuration file ? Something like:
>
> ./configure --prefix=/usr --httpd-home=/home/httpd \
> --exclude-modules=mod-XX1,mod-XX2
>
> Wouldn't that be handy ? Instead of browsing through a config file and
> setting yourself compiler flags, library paths - you could have everything
> done for you by autoconf.
No. This is a really cool way to make sure that you never get the same
build of Apache twice (or any other autoconfed package). This is one
"feature" of autoconf that drives me completely crazy. Try sharing
sysadmin on a machine in the face of this kind of stuff going on.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: apache/linux modules
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, Feb 02, 1998 at 02:19:04PM -0700, Marc Slemko wrote:
> Oh yea, while are are at it... _WHY_ are there so many reports of the
> RedHat RPM of Apache 1.2.x not giving text/html to .htm files? The base
> version should...
I have to check this to be sure (I'm at work, with no access to a
Linux box), but I think Red Hat's Apache RPM doesn't use Apache's
mime.types file, but Red Hat's. There aren't many differences, but
maybe the htm suffix is among them?
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"'Why do you blow on people?' I don't know." -- Benny Hinn
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Marc Slemko wrote:
> There _is_ active work required to add the module to the directory;
> I'm not convinced that making them add a line to the conf file would
> change anything. You will still have people with problems that can't
> figure out that it is because they changed this or that.
<AOL>Precisely my point.</AOL>
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> Cristian Gafton wrote:
> >
> > Try to look at this from a distribution maintainer point of view. We'd
> > like to be able to ship aoache modules for Red Hat systems to include
> > postgres support, other cool stuff, without having to rebuild the apache
> > binary package every time... It is not only cool, buty it will make apache
> > easy to deploy on a lot of other cases (think about products like miniSQL,
> > mySQL, Solid server, etc, shipping their version of apache module and all
> > you have to do is to stick it into a directory and apache will start using
> > it..)
>
> Perhaps I'm speaking out of turn here, but it seems to me that
> RedHat does *not* have a very good record when it comes to shipping
The less changes required the better and the fewer chances for
problems. If we can get some mutually acceptable way for doing
dynamic stuff, we not only get someone else who can work on it but
it is then in the base version of Apache. It _is_ something useful
to support.
There _is_ active work required to add the module to the directory;
I'm not convinced that making them add a line to the conf file would
change anything. You will still have people with problems that can't
figure out that it is because they changed this or that.
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> a working Apache Web server with no more bugs than in what *we*
> release. I recall a lot of reports of strange problems that were
A "lot" ?! Let me tell you what I saw: people complaining about not being
able to compile the mysql stuff or php with minisql and/or postgres and
bitching at us "why RH does not ship PHP with miniSQL enabled". To which
our response was "sorry, to make apache require to have installed postgres
or minisql to make it work it will be absurd".
Now, if we did have modules...
> eventually traced back to the RedHat-specific distribution. And
> for the last couple/few releases of RedHat, at that. I don't know
Saying that about the OS that brought Apache the largest amount of market
share comes naturally. After all, there are millions out there running RH
Linux with apache turned on - how would you expect that the errors
reported and the number of users not being able to figure out something
not to be the high ?
> how many of the resulting "it doesn't work" reports go to RedHat,
> but a distressing number of them come our way.
We do get plenty of them, rest assured. However, I am here in a
development mission, not to defend RH against some statistics.
> Adding value is good. But the flexibility you tout in the above
> paragraph seems to me to be adding numerous dimensions to how the
> distribution could be screwed up. Which means more bug reports for us.
To which you can blame us and send them to redhat-list@redhat.com. And
they'll be taken care of there.
> Someone "sticks the module into a directory" and suddenly the server
> starts misbehaving. Worse, they stick it in the directory before
> starting the server for the first time, so when it breaks it looks
> like it's always been that way.
I am sure that stupid scenarios are numerous, starting with wornly
modifying a config file, etc. You can not rely on the fact that some users
are morons :-)
> new modules requires active work by the Webmaster so its quite aware
> of the change.
And installing a module is not 'active' work ?
Having the server load only modules with a certain compatibility signature
will be one way to protect the server from doing stupid things.
> Then there's the potential that the Webmaster will
> make the connexion between the change and the brokenness. Unlikely,
> I know - but a greater probability, I think, than in the "drop-in
> module" scenario.
That's what the error logs are for.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Cristian Gafton wrote:
>
> Try to look at this from a distribution maintainer point of view. We'd
> like to be able to ship aoache modules for Red Hat systems to include
> postgres support, other cool stuff, without having to rebuild the apache
> binary package every time... It is not only cool, buty it will make apache
> easy to deploy on a lot of other cases (think about products like miniSQL,
> mySQL, Solid server, etc, shipping their version of apache module and all
> you have to do is to stick it into a directory and apache will start using
> it..)
Perhaps I'm speaking out of turn here, but it seems to me that
RedHat does *not* have a very good record when it comes to shipping
a working Apache Web server with no more bugs than in what *we*
release. I recall a lot of reports of strange problems that were
eventually traced back to the RedHat-specific distribution. And
for the last couple/few releases of RedHat, at that. I don't know
how many of the resulting "it doesn't work" reports go to RedHat,
but a distressing number of them come our way.
Adding value is good. But the flexibility you tout in the above
paragraph seems to me to be adding numerous dimensions to how the
distribution could be screwed up. Which means more bug reports for us.
Someone "sticks the module into a directory" and suddenly the server
starts misbehaving. Worse, they stick it in the directory before
starting the server for the first time, so when it breaks it looks
like it's always been that way. No, thanks - that makes our
software look like a crock of that-which-fertilises even though
it's not our fault. I much prefer a situation in which adding
new modules requires active work by the Webmaster so its quite aware
of the change. Then there's the potential that the Webmaster will
make the connexion between the change and the brokenness. Unlikely,
I know - but a greater probability, I think, than in the "drop-in
module" scenario.
Perhaps I'm gun-shy - I've been in the 'helpline' business for a
loooong time. The number of ways in which end-users can consume
support time beggars the imagination.
Just FWIW, and with no animosity.
#ken P-)}
#ken P-)}
Re: mod_so committed (was Re: apache/linux modules)
Posted by Brian Behlendorf <br...@organic.com>.
At 11:00 AM 2/3/98 +0000, Paul Sutton wrote:
>Right, I've committed Sameer's mod_so and my SharedModule compilation
>command, so people can start using shared modules.
As cartman says, "kick-ass!!" Thanks, Paul.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: future plans
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 5 Feb 1998, Ben Laurie wrote:
> I'm not convinced its as simple as this. For example, if I avoid calling
> things by inlining (== big) then is that really slower?
It can be. Especially on x86 processors -- there just aren't enough
registers to take complete advantage of inlined code. Alan Cox has shown
a linux kernel that's faster by not inlining the functions which do copies
from user to kernel and vice versa. On risc processors you can usually
eat up inlined code by register renaming and filling in more delay slots.
> Can we quantify what this actually means, please? Like, a list of
> platforms, and what their C++ support is would be good. Also a list of
> platforms we care about (in the 2.0 timeframe. So anything with year
> 2000 problems is out :-).
The only platforms I'm personally interested in are Unix based (ok ok
POSIX) and are still supported by their vendor. If we leave the
unsupported ones behind I won't mind. They'll still have Apache 1.x.
> > Then I'm +0 on using C++.
>
> Wow! I'm making progress!
:)
Dean
Re: future plans
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Thu, 5 Feb 1998, Ben Laurie wrote:
>
> > Unfortunately, I find it hard to get motivated about API redesign since
> > this group consistently rejects the only _sensible_ way forward (i.e.
> > C++), on grounds that are becoming increasingly shaky. I do sympathize
> > with those who don't yet know C++ well (or at all) but hell, guys,
> > you've got to start somewhere, right?
>
> If we can maintain the mentality that "lean is good", which means that C++
> weenies do not get to link in 5 zillion class libraries just because they
> don't want to code up a linked list or some other silliness like that. I'm
> not going to be happy with an apache that's twice its current size. (This
> is where theory and reality collide -- small == less instruction cache
> footprint == faster.)
I'm not convinced its as simple as this. For example, if I avoid calling
things by inlining (== big) then is that really slower?
> And we can avoid the really broken "features" of C++, like operator
> overloading (yeah sure, theoretically a cool thing, but try debugging a
> program that (ab)uses this "feature").
I'm not saying this is going to be a completely painless process. Given
that major code bloat and obscurity is an easy-to-achieve side effect of
careless C++, we need to keep an eye on these things, but dismissing
whole language features out of hand because of a bad experience is
really taking it a bit far.
> And we can be happy that we're not losing platforms that we care about.
> (In order to decide this we have to decide what intersection of "features"
> we're going to use.)
Can we quantify what this actually means, please? Like, a list of
platforms, and what their C++ support is would be good. Also a list of
platforms we care about (in the 2.0 timeframe. So anything with year
2000 problems is out :-).
> Then I'm +0 on using C++.
Wow! I'm making progress!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: future plans
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 5 Feb 1998, Ben Laurie wrote:
> Unfortunately, I find it hard to get motivated about API redesign since
> this group consistently rejects the only _sensible_ way forward (i.e.
> C++), on grounds that are becoming increasingly shaky. I do sympathize
> with those who don't yet know C++ well (or at all) but hell, guys,
> you've got to start somewhere, right?
If we can maintain the mentality that "lean is good", which means that C++
weenies do not get to link in 5 zillion class libraries just because they
don't want to code up a linked list or some other silliness like that. I'm
not going to be happy with an apache that's twice its current size. (This
is where theory and reality collide -- small == less instruction cache
footprint == faster.)
And we can avoid the really broken "features" of C++, like operator
overloading (yeah sure, theoretically a cool thing, but try debugging a
program that (ab)uses this "feature").
And we can be happy that we're not losing platforms that we care about.
(In order to decide this we have to decide what intersection of "features"
we're going to use.)
Then I'm +0 on using C++.
Dean
Re: future plans
Posted by Ben Laurie <be...@algroup.co.uk>.
Brian Behlendorf wrote:
>
> At 08:01 AM 2/3/98 -0500, Jim Jagielski wrote:
> >To me, it's looking like there is still a lot we could do with 1.3.0.
>
> Indeed.
>
> > 1. We stop development on 1.3 in order to release 1.3.0.
> > We focus on 2.0.
>
> I think the problems we've all had regarding 2.0 development have been
> around having much larger plans than any of us can reasonably do in a given
> amount of time.
>
> What if we said that the only major advances we *needed* to have in 2.0 was
> multithreading. A new API would be nice (we can get partway there with
> some extra phases), as well layered IO or a new config language, but
> ultimately the most pressing issue in apache compared to other servers is
> the multithreading issue. The hard part will be coming up with a portable
> threading interface, something which runs in front of pthreads, or native
> threads, or even a multi-process emulation of threading. The core code
> should be mostly thread safe particularly since the NT port is
> multithreaded anyways.
>
> Since threading is pretty closely tied with IO it might make sense to also
> do the IO stuff we've talked about at the same time... but I really do see
> everyone's plans for 2.0 being much larger than I think any of us will be
> able to chew anytime soon.
>
> If someone comes up with a proposed threading interface spec, and backs it
> with pthreads, that'll get us a huge chunk of the way there; other
> threading models can be implemented as 2.0 rolls through alpha. The basic
> idea, though, is to lower our aims for what 2.0 will include.
>
> comments?
This makes a lot of sense to me. Threading + I/O is what we really need,
though a radical API redesign wouldn't be such a bad thing.
Unfortunately, I find it hard to get motivated about API redesign since
this group consistently rejects the only _sensible_ way forward (i.e.
C++), on grounds that are becoming increasingly shaky. I do sympathize
with those who don't yet know C++ well (or at all) but hell, guys,
you've got to start somewhere, right?
Now that STL and friends are with us, and templates are more-or-less
universally supported, the benefits of C++ are becoming so vast they are
hard to ignore. Apache is now the _only_ program I spend any significant
amount of time on that is still in C. And for those who still want a C
API, I really can't see that there's a problem (though it is likely to
be rather clunky in comparison to a C++ one).
So, I'd support 2.0 (or 1.4) being threads+I/O, and 3.0 (or 2.0) being
C++ and radical API redesign.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
future plans
Posted by Brian Behlendorf <br...@organic.com>.
At 08:01 AM 2/3/98 -0500, Jim Jagielski wrote:
>To me, it's looking like there is still a lot we could do with 1.3.0.
Indeed.
> 1. We stop development on 1.3 in order to release 1.3.0.
> We focus on 2.0.
I think the problems we've all had regarding 2.0 development have been
around having much larger plans than any of us can reasonably do in a given
amount of time.
What if we said that the only major advances we *needed* to have in 2.0 was
multithreading. A new API would be nice (we can get partway there with
some extra phases), as well layered IO or a new config language, but
ultimately the most pressing issue in apache compared to other servers is
the multithreading issue. The hard part will be coming up with a portable
threading interface, something which runs in front of pthreads, or native
threads, or even a multi-process emulation of threading. The core code
should be mostly thread safe particularly since the NT port is
multithreaded anyways.
Since threading is pretty closely tied with IO it might make sense to also
do the IO stuff we've talked about at the same time... but I really do see
everyone's plans for 2.0 being much larger than I think any of us will be
able to chew anytime soon.
If someone comes up with a proposed threading interface spec, and backs it
with pthreads, that'll get us a huge chunk of the way there; other
threading models can be implemented as 2.0 rolls through alpha. The basic
idea, though, is to lower our aims for what 2.0 will include.
comments?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: mod_so committed (was Re: apache/linux modules)
Posted by Paul Sutton <pa...@awe.com>.
On Tue, 3 Feb 1998, Alexei Kosut wrote:
> Yeah. As I see it, there are several ways to do this:
>
> 1. deduce the structure name from the filename
> 2. rename the structure to be the same on all shared modules
> 3. some sort of meta-information, e.g. a seperate file.
or
4. add a known entry point function with the same name in every module
which returns (a pointer to) the module's structure.
Option 1 is good for backward compatability. Unfortunately there are a few
modules which don't quite follow the de facto "rules"... (e.g. mod_include
=> includes_module). Doh. My Configure stuff gets round this by grepping
the source for the module structure definition line :-).
> The third option strikes me as undesired, especially if we want to enable
> a "drop a module in a directory to add it to Apache" mode, since that
> would involve additional files.
Agreed.
//pcs
Re: mod_so committed (was Re: apache/linux modules)
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 3 Feb 1998, Paul Sutton wrote:
> Some things that would be nice are:
>
> - support for more than Linux & FreeBSD. This should be a simple case of
> adding the correct values for CFLAGS_SHLIB, LDFLAGS_SHLIB and
> LDFLAGS_SHLIB_EXPORT in Configuration (see the Linux section for
> examples)
I heard somewhere that some program called autoconf was good at this.
Never heard of it, personally :)
> - not requiring the module structure name on the LoadModule directive
> (we got rid of this from Configuration by changing Module to AddModule
> and allowing for .module or embedded configurations in module source.
> something similar to LoadModule would be good)
Yeah. As I see it, there are several ways to do this:
1. deduce the structure name from the filename
2. rename the structure to be the same on all shared modules
3. some sort of meta-information, e.g. a seperate file.
The third option strikes me as undesired, especially if we want to enable
a "drop a module in a directory to add it to Apache" mode, since that
would involve additional files.
[...]
> - a test suite to test whether things are actually working as expected
> ;-)
Who needs test suites? We all write perfect code... :)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
[PATCH] unload/reload dynamic modules (was Re: mod_so committed)
Posted by Paul Sutton <pa...@c2.net>.
On Tue, 3 Feb 1998, Alexei Kosut wrote:
> On Tue, 3 Feb 1998, Dean Gaudet wrote:
> > > - support for dropping modules & reloading during a restart
> > What happens now?
>
> Both mod_dll, mod_so and mod_dld (on which the other two are based) only
> recognize LoadModule directives on startup. They get ignored on restart.
> It probably wouldn't be too hard to check each LoadModule to see if it was
> "new", and add it, and then see if any were "missing", and drop them.
Ok, here is a patch to unload dynamically loaded modules during a restart.
It basically adds the module's handle as a clean-up for the cmd->pool
pool. The cleanup unloads the file, and drops the module's structure from
the linked-list of modules (remove_module() in http_config.h). The new
item dynamic_load_handle is added to the module structure, and set to NULL
by STANDARD_MODULE_STUFF (but this means that _all_ modules will need to
at least be recompiled).
This patch is for Unix only, I also have a patch for Win32 which adds the
unload stuff for DLLs (it is basically identical, in fact I developed this
on NT then ported it back to mod_so). It only currently works for
LoadModule modules, not LoadFile (is there any real use for LoadFile??).
It isn't difficult to add LoadFile reloading though.
With this patch you can now change your LoadModule lines, do a HUP or
USR1, and get an Apache with your new set of modules. So you can extend
your server without ever bringing it down! I think that's pretty neat.
//pcs
Index: include/http_config.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/http_config.h,v
retrieving revision 1.63
diff -u -r1.63 http_config.h
--- http_config.h 1998/02/01 22:05:33 1.63
+++ http_config.h 1998/02/04 13:28:47
@@ -176,6 +176,8 @@
const char *name;
+ void *dynamic_load_handle;
+
struct module_struct *next;
/* init() occurs after config parsing, but before any children are
@@ -254,7 +256,7 @@
*/
#define MODULE_MAGIC_NUMBER 19980201
-#define STANDARD_MODULE_STUFF MODULE_MAGIC_NUMBER, -1, __FILE__, NULL
+#define STANDARD_MODULE_STUFF MODULE_MAGIC_NUMBER, -1, __FILE__, NULL, NULL
/* Generic accessors for other modules to get at their own module-specific
* data
Index: main/http_config.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/main/http_config.c,v
retrieving revision 1.95
diff -u -r1.95 http_config.c
--- http_config.c 1998/02/02 22:33:31 1.95
+++ http_config.c 1998/02/04 13:28:52
@@ -530,6 +530,48 @@
build_method_shortcuts();
}
+/*
+ * remove_module undoes what add_module did. There are some caveats:
+ * when the module is removed, its slot is lost so all the current
+ * per-dir and per-server configurations are invalid. So we should
+ * only ever call this function when you are invalidating almost
+ * all our current data. I.e. when doing a restart.
+ */
+
+API_EXPORT(void) remove_module(module *m)
+{
+ module *modp;
+
+ modp = top_module;
+ if (modp == m) {
+ /* We are the top module, special case */
+ top_module = modp->next;
+ }
+ else {
+ /* Not the top module, find use. When found modp will
+ * point to the module _before_ us in the list
+ */
+
+ while (modp && modp->next != m) {
+ modp = modp->next;
+ }
+ if (!modp) {
+ /* Uh-oh, this module doesn't exist */
+ aplog_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, NULL,
+ "Cannot remove module %s: not found in module list",
+ m->name);
+ return;
+ }
+ /* Eliminate us from the module list */
+ modp->next = modp->next->next;
+ }
+
+ m->module_index = -1; /* simulate being unloaded, should
+ * be unnecessary */
+ dynamic_modules--;
+}
+
+
void setup_prelinked_modules()
{
module **m;
Index: modules/standard/mod_so.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_so.c,v
retrieving revision 1.2
diff -u -r1.2 mod_so.c
--- mod_so.c 1998/02/04 10:22:18 1.2
+++ mod_so.c 1998/02/04 13:28:55
@@ -1,5 +1,5 @@
/* ====================================================================
- * Copyright (c) 1995-1997 The Apache Group. All rights reserved.
+ * Copyright (c) 1995-1998 The Apache Group. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -120,24 +120,37 @@
#define RTLD_LAZY 1
#endif
-/*
- * The hard part of implementing LoadModule is deciding what to do about
- * rereading the config files. This proof-of-concept implementation takes the
- * cheap way out: we only actually load the modules the first time through.
- */
-
-static int been_there_done_that = 0; /* Loaded the modules yet? */
static int have_symbol_table = 0;
#ifndef NO_DLOPEN
+
+/* This is the cleanup for a loaded DLL. It unloads the module */
+void unload_module(module *modp)
+{
+ char mod_name[50]; /* Um, no pool, so make this auto */
+
+ /* Take a copy of the module name so we can report that it has been
+ * unloaded (since modp itself will have been unloaded). */
+ strncpy(mod_name, modp->name, 49);
+ mod_name[49] = '\0';
+
+ remove_module(modp);
+
+ /* The Linux manpage doesn't give any way to check the success of
+ * dlclose(). */
+ dlclose(modp->dynamic_load_handle);
+
+ aplog_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, NULL,
+ "unloaded module %s", mod_name);
+}
+
+/* load_module is called for the directive LoadModule */
static const char *load_module (cmd_parms *cmd, void *dummy, char *modname, char *filename)
{
void *modhandle;
module *modp;
const char *szModuleFile=server_root_relative(cmd->pool, filename);
- if (been_there_done_that) return NULL;
-
if (!(modhandle = dlopen(szModuleFile, RTLD_NOW)))
{
const char *my_error = dlerror();
@@ -146,10 +159,6 @@
NULL);
}
- /* If I knew what the correct cast is here, I'd be happy. But
- * I don't. So I'll use (void *). It works.
- */
-
aplog_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, NULL,
"loaded module %s", modname);
@@ -162,8 +171,18 @@
" in file ", filename, ":", dlerror(), NULL);
}
+ modp->dynamic_load_handle = modhandle;
+ printf("load_module: m->dlh=%p\n", modp->dynamic_load_handle);
+
add_module (modp);
+ /* Register a cleanup in the config pool (normally pconf). When
+ * we do a restart (or shutdown) this cleanup will cause the
+ * DLL to be unloaded.
+ */
+ register_cleanup(cmd->pool, modp,
+ (void (*)(void*))unload_module, null_cleanup);
+
/* Alethea Patch (rws,djw2) - need to run configuration functions
in new modules */
@@ -181,8 +200,6 @@
static const char *load_file (cmd_parms *cmd, void *dummy, char *filename)
{
- if (been_there_done_that) return NULL;
-
if (!dlopen(server_root_relative(cmd->pool, filename), 1))
return pstrcat (cmd->pool, "Cannot load ", filename, " into server", NULL);
@@ -191,26 +208,17 @@
#else
static const char *load_file(cmd_parms *cmd, void *dummy, char *filename)
{
- if(!been_there_done_that)
- fprintf(stderr, "WARNING: LoadFile not supported\n");
+ fprintf(stderr, "WARNING: LoadFile not supported\n");
return NULL;
}
static const char *load_module(cmd_parms *cmd, void *dummy, char *modname, char *filename)
{
- if(!been_there_done_that)
- fprintf(stderr, "WARNING: LoadModule not supported\n");
+ fprintf(stderr, "WARNING: LoadModule not supported\n");
return NULL;
}
#endif
-static void check_loaded_modules (server_rec *dummy, pool *p)
-{
- if (been_there_done_that) return;
-
- been_there_done_that = 1;
-}
-
command_rec so_cmds[] = {
{ "LoadModule", load_module, NULL, RSRC_CONF, TAKE2,
"a module name, and the name of a file to load it from"},
@@ -221,7 +229,7 @@
module so_module = {
STANDARD_MODULE_STUFF,
- check_loaded_modules, /* initializer */
+ NULL, /* initializer */
NULL, /* create per-dir config */
NULL, /* merge per-dir config */
NULL, /* server config */
Re: mod_so committed (was Re: apache/linux modules)
Posted by Paul Sutton <pa...@awe.com>.
On Tue, 3 Feb 1998, Alexei Kosut wrote:
> BTW, I think it would be a good idea if the SharedModule configure thing
> added a -DSHARED_MODULE to the cc arguments when it builds the module.
> That way, modules could behave differently when they are built shared.
Yep, +1. I've added it.
//pcs
Re: mod_so committed (was Re: apache/linux modules)
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 3 Feb 1998, Dean Gaudet wrote:
> > - support for dropping modules & reloading during a restart
>
> What happens now?
Both mod_dll, mod_so and mod_dld (on which the other two are based) only
recognize LoadModule directives on startup. They get ignored on restart.
It probably wouldn't be too hard to check each LoadModule to see if it was
"new", and add it, and then see if any were "missing", and drop them.
*shrug*
BTW, I think it would be a good idea if the SharedModule configure thing
added a -DSHARED_MODULE to the cc arguments when it builds the module.
That way, modules could behave differently when they are built shared.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: mod_so committed (was Re: apache/linux modules)
Posted by Paul Sutton <pa...@awe.com>.
On Tue, 3 Feb 1998, Dean Gaudet wrote:
> On Tue, 3 Feb 1998, Paul Sutton wrote:
> > - not requiring people to add -ldl to EXTRA_LIBS, if necessary on their
> > OS (another Configuration variable, maybe?)
>
> Shouldn't this be as simple as a .module for mod_so which looks for -ldl
> and adds it?
Yeah, it could be. I've now added this to the mod_so.c source. It might
need updating for other OSes which don't put this in -ldl.
//pcs
Re: mod_so committed (was Re: apache/linux modules)
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 3 Feb 1998, Paul Sutton wrote:
> - not requiring people to add -ldl to EXTRA_LIBS, if necessary on their
> OS (another Configuration variable, maybe?)
Shouldn't this be as simple as a .module for mod_so which looks for -ldl
and adds it?
> - support for dropping modules & reloading during a restart
What happens now?
Dean
mod_so committed (was Re: apache/linux modules)
Posted by Paul Sutton <pa...@awe.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> It would be really nice if this were supported directly by us. But
> there's still no compelling reason to change anything in the core, all
> that's needed is Sameer's module and the extra rules he built into
> Configure for building shared modules.
Right, I've committed Sameer's mod_so and my SharedModule compilation
command, so people can start using shared modules. We really should try
and get this useable for 1.3, since I think it will encourage a lot of
third-partly module development. At the very least it should and new, even
easier compilation models for big modules such as php3.
Some things that would be nice are:
- support for more than Linux & FreeBSD. This should be a simple case of
adding the correct values for CFLAGS_SHLIB, LDFLAGS_SHLIB and
LDFLAGS_SHLIB_EXPORT in Configuration (see the Linux section for
examples)
- not requiring people to add -ldl to EXTRA_LIBS, if necessary on their
OS (another Configuration variable, maybe?)
- not requiring the module structure name on the LoadModule directive
(we got rid of this from Configuration by changing Module to AddModule
and allowing for .module or embedded configurations in module source.
something similar to LoadModule would be good)
- auto load multiple modules from a directory
- a test suite to test whether things are actually working as expected
;-)
- extensive documentation to persuad third-party module authors that
they can create binary modules for Apache and give their users really
easy configuration instructions (a la: "drop mod_goodstuff.so into
httpd/modules and reload your server")
- support for dropping modules & reloading during a restart
- trashing mod_dld.c
//pcs
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> And I want something like this in the standard distribution, enable by
> uncomenting DYNAMIC_MODULES=1 in the Configuration file. Does that sounds
> reasonable ?
Have you looked at 1.3 yet? Isn't all this code in there? Or am I
smoking crack and it was part of a big patch from Sameer last november
which never got put into the server and which should have? Ah yes now I
see, it's part of sameer's dynamic patch.
Ok, so without sameer's patch (or other changes to the core), right now
you can do this:
- write your own mod_dynamic_whatever or steal one
- build a Configuration with that module in it, and none of the others
- somehow (you're the one doing the distribution) build the rest of the
modules as shared modules
Have a config file that includes a directive like:
LoadDynamicModules /wherever
right at the top. Then it's your module's job to clear the static module
list (woo big list, it just has your module in it), and add in all the
rest.
This is all possible now. Without changing a single line of code in the
core.
It would be really nice if this were supported directly by us. But
there's still no compelling reason to change anything in the core, all
that's needed is Sameer's module and the extra rules he built into
Configure for building shared modules.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> No, you're not. You can only AddModule modules that were included
> at compile-time. But you can disable the ones that were included
> that you don't want activated with this method.
How about 'I don't want no stinkin' modules eating my memory' disabling
facility ? I.e. don't load them at all ?
> you're using) is strictly a RedHat solution. Other distributors
NO. A solution for systems (modern systems) that support dynamic loading
of shared objects. It is a very normal thing to do.
> not necessarily better. Is the potential return from a successful
> experiment worth the investment?
I'm betting a beer on this one.
> run-time. It requires a change to the run-time configuration files.
> Which is certainly simpler than a recompilation - but TANSTAAFL.
And I want something like this in the standard distribution, enable by
uncomenting DYNAMIC_MODULES=1 in the Configuration file. Does that sounds
reasonable ?
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> It sounds like what you're lobbying for (at least the naming that
> you're using) is strictly a RedHat solution
Nah, it'll work for all linux, and with minor changes for FreeBSD and
solaris I'm sure. And anything else that we could port the dynamic module
loader to. This is a good goal, I'm entirely behind it. But I know your
support issues with it... so it would be entirely cool if this were in the
core.
Dean
Re: apache/linux modules
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Cristian Gafton wrote:
>
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > Apache doesn't have to be recompiled to change the list of modules.
> > ClearModules plus a dynamic AddModule does the job.
>
> Really ?!
>
> I want to ship PHP module for the apache as a separate package that
> included module-php.so.1.2.5 shared library. How do I make apache use it
> without recompiling ?
>
> Am I such a moron ?
No, you're not. You can only AddModule modules that were included
at compile-time. But you can disable the ones that were included
that you don't want activated with this method.
It sounds like what you're lobbying for (at least the naming that
you're using) is strictly a RedHat solution. Other distributors
would catch on (and up) eventually. I've nothing against it
on those grounds - I don't believe that "old is good" always
applies. I just want to point out at this juncture than new is
not necessarily better. Is the potential return from a successful
experiment worth the investment?
Sameer's mod_so allows you (I think) to pick up arbitrary modules at
run-time. It requires a change to the run-time configuration files.
Which is certainly simpler than a recompilation - but TANSTAAFL.
#ken P-)}
Re: apache/linux modules
Posted by Michael Douglass <mi...@texas.net>.
On Wed, Feb 04, 1998 at 12:28:48AM -0800, Alexei Kosut said:
> All code segments, AFAIK, are placed in shared memory. You don't save
> memory, really. And shared libs are still, I believe, reserved their own
> memory for each incarnation, since they do have their own variables and
> stack and things.
Hrmm.. Okay, I withdraw that argument.. As 'pmap' under solaris is
clearly showing me exactly what you are saying. :)
--
Michael Douglass
Texas Networking, Inc.
<tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
The apache core code for dynamic modules is less than optimal regarding
memory usage. That's what I'm referring to. Search for
DYNAMIC_MODULE_LIMIT.
Dean
On Wed, 4 Feb 1998, Michael Douglass wrote:
> On Mon, Feb 02, 1998 at 04:13:05PM -0800, Dean Gaudet said:
>
> > You'll waste some memory this route, but for the 90% case that isn't an
> > issue.
>
> Why would it be wasting memory with this route? I know that, at least
> under Solaris, .so code segments are placed in shared memory (hence
> 'shared libraries')... Wouldn't this actually save memory since having
> 100 servers running will have only a fraction of the amount of code
> space used for the modules as normal? To me this would be a good think.
>
> Is that what you mean by the 90% case??? And if that is the case,
> then this concept and idea should be touted as a thing to do. Although
> I _hardly_ would want a static-only or dynamic-only concept... One
> in which you have static modules and have the option of loading static
> modules seems a nice compromise.
>
> Or am I lost?
>
> --
> Michael Douglass
> Texas Networking, Inc.
>
> <tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady
>
Re: apache/linux modules
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Wed, 4 Feb 1998, Michael Douglass wrote:
> On Mon, Feb 02, 1998 at 04:13:05PM -0800, Dean Gaudet said:
>
> > You'll waste some memory this route, but for the 90% case that isn't an
> > issue.
>
> Why would it be wasting memory with this route? I know that, at least
> under Solaris, .so code segments are placed in shared memory (hence
> 'shared libraries')... Wouldn't this actually save memory since having
All code segments, AFAIK, are placed in shared memory. You don't save
memory, really. And shared libs are still, I believe, reserved their own
memory for each incarnation, since they do have their own variables and
stack and things.
The term 'shared libraries' comes from the fact that the library can be
shared among programs, without having to be incorporated into each, and
without having to recompile the program if the library changes. It's
shared code, not shared memory.
> 100 servers running will have only a fraction of the amount of code
> space used for the modules as normal? To me this would be a good think.
Most modern OSes do this anyway.
> Is that what you mean by the 90% case??? And if that is the case,
> then this concept and idea should be touted as a thing to do. Although
> I _hardly_ would want a static-only or dynamic-only concept... One
> in which you have static modules and have the option of loading static
> modules seems a nice compromise.
Dean is very much concerned, here, that Apache does not lose its ability
to work as a high-performance, high-speed, high-volume web server in our
zeal to make it better adapted to the average user (the 90% case). Which
is understandable.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: apache/linux modules
Posted by Michael Douglass <mi...@texas.net>.
On Mon, Feb 02, 1998 at 04:13:05PM -0800, Dean Gaudet said:
> You'll waste some memory this route, but for the 90% case that isn't an
> issue.
Why would it be wasting memory with this route? I know that, at least
under Solaris, .so code segments are placed in shared memory (hence
'shared libraries')... Wouldn't this actually save memory since having
100 servers running will have only a fraction of the amount of code
space used for the modules as normal? To me this would be a good think.
Is that what you mean by the 90% case??? And if that is the case,
then this concept and idea should be touted as a thing to do. Although
I _hardly_ would want a static-only or dynamic-only concept... One
in which you have static modules and have the option of loading static
modules seems a nice compromise.
Or am I lost?
--
Michael Douglass
Texas Networking, Inc.
<tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > If you've got a dynamic AddModule that works then yes it's this simple. I
> > suspect the problem is that mod_dld isn't, and mod_sameer's_dynloader or
> > mod_cristian's_dynloader aren't shipped by default.
>
> There is no module involved in what I propose: just dlopen() some shared
> objects, check them for compatibility and that's it...
Yes there is a module because that code doesn't belong in the core.
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> Maybe you're not familiar with the Apache API. It's there for a reason,
> so that the core doesn't have to contain the kitchen sink. I'd rather
> examine why the API is deficient than add dlopen() to the core. I'm sure
> others will agree.
Or this is another possibility, yes.
> For one thing, dlopen() doesn't work on win32, so another solution is
> needed there... that solution already exists, and is a module (mod_dll).
That's what #ifdef's are for :-)
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> There is no module involved in what I propose: just dlopen() some shared
> objects, check them for compatibility and that's it...
Maybe you're not familiar with the Apache API. It's there for a reason,
so that the core doesn't have to contain the kitchen sink. I'd rather
examine why the API is deficient than add dlopen() to the core. I'm sure
others will agree.
For one thing, dlopen() doesn't work on win32, so another solution is
needed there... that solution already exists, and is a module (mod_dll).
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> If you've got a dynamic AddModule that works then yes it's this simple. I
> suspect the problem is that mod_dld isn't, and mod_sameer's_dynloader or
> mod_cristian's_dynloader aren't shipped by default.
There is no module involved in what I propose: just dlopen() some shared
objects, check them for compatibility and that's it...
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
If you've got a dynamic AddModule that works then yes it's this simple. I
suspect the problem is that mod_dld isn't, and mod_sameer's_dynloader or
mod_cristian's_dynloader aren't shipped by default.
If that doesn't work then I consider it a bug in 1.3.
You'll waste some memory this route, but for the 90% case that isn't an
issue.
Dean
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > Apache doesn't have to be recompiled to change the list of modules.
> > ClearModules plus a dynamic AddModule does the job.
>
> Really ?!
>
> I want to ship PHP module for the apache as a separate package that
> included module-php.so.1.2.5 shared library. How do I make apache use it
> without recompiling ?
>
> Am I such a moron ?
>
> Cristian
> --
> ----------------------------------------------------------------------
> Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> UNIX is user friendly. It's just selective about who its friends are.
>
>
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> Apache doesn't have to be recompiled to change the list of modules.
> ClearModules plus a dynamic AddModule does the job.
Really ?!
I want to ship PHP module for the apache as a separate package that
included module-php.so.1.2.5 shared library. How do I make apache use it
without recompiling ?
Am I such a moron ?
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> I understand you point, but please do not discard mine - those aimed at
> making distributions have to think about providing config tools to their
> users - and currently the way apache have to be recompiled to modify it's
> list of modules this is a very hard to do thing.
Apache doesn't have to be recompiled to change the list of modules.
ClearModules plus a dynamic AddModule does the job.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Rodent of Unusual Size wrote:
> Um. So you either have to move/copy the modules that you do want loaded
> to a particular directory so the server will find them - or else remove
> the ones you *don't* want so the server *won't* find them. Either I'm
> missing something (probable) or else this is even more complex and problem-
> prone than the current "vi Configuration ; ./Configure ; make" arrangement.
You're missing the most important fact: you _are_ a hacker and you keep
the source for the apache server around. What if the complete newbie wants
to install a mySQL database and have an apache module provide
authetication to that database ? Do _you_ have time to explain to him how
to re-compile, how to edit a config file, etc ? He is using a binary
dostribution, and he doesn't want to play this game !
You miss something: you forget to ask youself how many of the over 50% of
the webmasters of the sites running Apache in the world are like you,
poking at the source, and how many are using binary packages already
provided by some vendors.
And I am talling you that is a whole lot easier to write a config tool
that will make some links in a directory so that apache will load new
modules than to write a config tool that will recompile apache every
time... What if he doesn't have a compiler installed, just because that is
a web server, not a development machine ?
I understand you point, but please do not discard mine - those aimed at
making distributions have to think about providing config tools to their
users - and currently the way apache have to be recompiled to modify it's
list of modules this is a very hard to do thing.
BTW: why the heck are they called "modules" ? Because you can compile them
in or not compile them in ? That is not the "definition" of the modules as
I understand it. And in most other cases when it is a talk about modules
this is not the sense most people understand it.
Best wishes,
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Cristian Gafton wrote:
>
> Yes, modules.c not being created automatically by Configure script. Just a
> generic init function that will look for modules and load them.
Um. So you either have to move/copy the modules that you do want loaded
to a particular directory so the server will find them - or else remove
the ones you *don't* want so the server *won't* find them. Either I'm
missing something (probable) or else this is even more complex and problem-
prone than the current "vi Configuration ; ./Configure ; make" arrangement.
#ken P-)}
Re: apache/linux modules
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> On Mon, 2 Feb 1998, Cristian Gafton wrote:
>
> > On Mon, 2 Feb 1998, Marc Slemko wrote:
> >
> > > Sure it is. mod_dld.c. It just doesn't work.
> >
> > That is dead... dld is dead... For a loooong time... Don't kid yourself
> > with something that will *never* work... At elast on modern Linux and *BSD
> > systems...
>
> If this is the case then lets remove it from the distribution and replace
> it with Sameer's module or something else.
>
> > > Sameer's mod_something (erm... mod_so) works under FreeBSD I think.
> > > Relies on dlopen/dlsym.
mod_so's status is in the .. erm, the STATUS file. There's been
nothing new on it since November, when Sameer brought up the issue of
locating symbols whose name involve funky underbar *fixes. I think
the suggestion was to do a dlsym lookup on all permutations, but
I think the project fell on the floor.
#ken P-)}
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> If this is the case then lets remove it from the distribution and replace
> it with Sameer's module or something else.
I am not sure that there is any system taht compiles the dld module
anymore. The dld library is now three years old... And obsoleted by the
bew dl stuff (dlopen and friends)
> This should be a trivial tweak to any working dynamic loading module. Add
> a config time directive "LoadModuleDir /wherever" and do the work then.
That is what I am about to do.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Marc Slemko wrote:
>
> > Sure it is. mod_dld.c. It just doesn't work.
>
> That is dead... dld is dead... For a loooong time... Don't kid yourself
> with something that will *never* work... At elast on modern Linux and *BSD
> systems...
If this is the case then lets remove it from the distribution and replace
it with Sameer's module or something else.
> > Sameer's mod_something (erm... mod_so) works under FreeBSD I think.
> > Relies on dlopen/dlsym.
>
> That is different from what I am trying. With the mod_so you actually
> have to "LoadModule mod-blah.so" in the config files. What I am trying is
> to have apache load _all_ modules from a directory as they were all
> compiled in when it starts, without any need to modify the config files...
This should be a trivial tweak to any working dynamic loading module. Add
a config time directive "LoadModuleDir /wherever" and do the work then.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Marc Slemko wrote:
> Sure it is. mod_dld.c. It just doesn't work.
That is dead... dld is dead... For a loooong time... Don't kid yourself
with something that will *never* work... At elast on modern Linux and *BSD
systems...
> Sameer's mod_something (erm... mod_so) works under FreeBSD I think.
> Relies on dlopen/dlsym.
That is different from what I am trying. With the mod_so you actually
have to "LoadModule mod-blah.so" in the config files. What I am trying is
to have apache load _all_ modules from a directory as they were all
compiled in when it starts, without any need to modify the config files...
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> > "supposed to work" is the operative phrase though... it's the same with
> > apache... modules should work, unless we change MODULE_MAGIC_NUMBER. Which
>
> No, it is difefrent. Apache loading it's modules at start time is not
> supposed to work because the code is not in there :-)
Sure it is. mod_dld.c. It just doesn't work.
Sameer's mod_something (erm... mod_so) works under FreeBSD I think.
Relies on dlopen/dlsym.
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> This is a dynamic only solution. We can't drop static support.
Correct. I am saying that we shopuld have a way to do dynamic only stuff.
> If you're building a dynamic only server then you don't need to list any
> modules in Configuration...
Well, you will list the modules you want to compile, so that some
makefiles will be generated :-)
> and I'm confused how autoconf helps this at
> all because as you said, for the 90% case only one build is done, and
> you're the one doing it (ok you or someone else at redhat).
Hmm ... my error, I was talking about two different things: having apache
support modules as shared libraries and load them on start time and having
support for autoconf. The later is a longer and bigger project, while the
shared stuff is amazingly simple to adopt (at least for linux platforms,
but I am sure that with minor tweaks we will have more platforms support)
Eventually, when autoconf thing will merge in, the whole dynamic stuff
will be just an --with-dynamic-modules flag :-)
> "supposed to work" is the operative phrase though... it's the same with
> apache... modules should work, unless we change MODULE_MAGIC_NUMBER. Which
No, it is difefrent. Apache loading it's modules at start time is not
supposed to work because the code is not in there :-)
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > Yes this is a great thing, but autoconf is orthogonal to this problem.
> > You essentially just need dynamic loading.
>
> Yes, modules.c not being created automatically by Configure script. Just a
> generic init function that will look for modules and load them.
This is a dynamic only solution. We can't drop static support.
If you're building a dynamic only server then you don't need to list any
modules in Configuration... and I'm confused how autoconf helps this at
all because as you said, for the 90% case only one build is done, and
you're the one doing it (ok you or someone else at redhat).
> > loading than, say, linux kernel modules ;) Every time you build a new
> > kernel for distribution you're stuck building new iBCS, new pcmcia-cs, and
> > whatever other addons you build.
>
> That is not necessarily true. We rebuild thos packages only because they
> are in fact sub-packages of the kernel RPM, so each time we generate a new
> kernel RPM we will generate those sub-packages anyway. But the Linux
> kernel modules are supposed to work.... <this is off-topic>
"supposed to work" is the operative phrase though... it's the same with
apache... modules should work, unless we change MODULE_MAGIC_NUMBER. Which
we don't tend to do in the stable tree, for obvious reasons.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> Yes. If you read the perf-tuning docs you'll see that Apache reserves
> extra memory for dynamic loading, you can save a nice hunk of memory by
I won't use thatextra memory... I have told you what I was thinking of:
- when the apache starts, build a list of modules available in a
directory, dlopen() and build the arrays build by the Configure script in
the modules.c file. By the time apache really starts the modules are
loaded. Being shared objects, the impact on memory consumption is minimal,
if any.
> build a performance critical server I tune a lot of *compile-time-only*
> configurables. So it's nothing much to link in exactly the modules the
> server will run.
Again, I am talking about the 90% of the market of the apache: the web
server run by some joe user that hardly takes few K hits per day. If you
have 1 milion hits per day, you will be able to find somebody to take care
of the fine tuning of the apache for you, and then our work for a
distribution will be pointless in that case anyway.
> Yes this is a great thing, but autoconf is orthogonal to this problem.
> You essentially just need dynamic loading.
Yes, modules.c not being created automatically by Configure script. Just a
generic init function that will look for modules and load them.
> loading than, say, linux kernel modules ;) Every time you build a new
> kernel for distribution you're stuck building new iBCS, new pcmcia-cs, and
> whatever other addons you build.
That is not necessarily true. We rebuild thos packages only because they
are in fact sub-packages of the kernel RPM, so each time we generate a new
kernel RPM we will generate those sub-packages anyway. But the Linux
kernel modules are supposed to work.... <this is off-topic>
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > *everywhere* (i.e. never) we have to support the configuration file... and
> > even if we could do dynamic loading everywhere, I wouldn't be using it on
> > a performance critical server.
>
> Wait a minute... WHY ?! Why can't you use the dynamic loadable modules on
> a performance critical server ? It's the same thing as having apache
> linked dynamically against libc... Are you saying that this will slow
> things down ?
Yes. If you read the perf-tuning docs you'll see that Apache reserves
extra memory for dynamic loading, you can save a nice hunk of memory by
disabling that (how much depends on your config). Furthermore when I
build a performance critical server I tune a lot of *compile-time-only*
configurables. So it's nothing much to link in exactly the modules the
server will run.
> Try to look at this from a distribution maintainer point of view. We'd
> like to be able to ship aoache modules for Red Hat systems to include
> postgres support, other cool stuff, without having to rebuild the apache
> binary package every time... It is not only cool, buty it will make apache
> easy to deploy on a lot of other cases (think about products like miniSQL,
> mySQL, Solid server, etc, shipping their version of apache module and all
> you have to do is to stick it into a directory and apache will start using
> it..)
Yes this is a great thing, but autoconf is orthogonal to this problem.
You essentially just need dynamic loading. If you need more than that
then we've messed up... but I don't think we're any worse at dynamic
loading than, say, linux kernel modules ;) Every time you build a new
kernel for distribution you're stuck building new iBCS, new pcmcia-cs, and
whatever other addons you build. Apache is pretty similar this way, if
there's been a MODULE_MAGIC_NUMBER increase.
> > have the issue of translating all of the apache architecture names to the
> > equivalent autoconf names and then debugging the entire mess. Not a small
> > job.
>
> Any volunteers ? :-) I am one.
Prepare yourself for lots of discussion! :)
Dean
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> > We provide reasonable defaults in Configuration. ./Configure from a
> > freshly unpacked apache should provide a working program on most systems.
> > The exceptions are those that vary greatly from one distribution to
> > another (i.e. linux)... and that I've tried to deal with in 1.3.
>
> Try to look at this from a distribution maintainer point of view. We'd
> like to be able to ship aoache modules for Red Hat systems to include
> postgres support, other cool stuff, without having to rebuild the apache
> binary package every time... It is not only cool, buty it will make apache
> easy to deploy on a lot of other cases (think about products like miniSQL,
> mySQL, Solid server, etc, shipping their version of apache module and all
> you have to do is to stick it into a directory and apache will start using
> it..)
Let me just add to this discussion that, despite negative reaction about
ways to do things, I think we fully support this concept and making it
easier for vendors to package and change module configuration without
recompiling. Various packages of Apache have to do a lot of things right
now that they simply shouldn't have to. It is just a matter of being
leery of certain methods which aren't really well-liked.
Right now, however, you also have the limited module magic number scheme
that is unnecessarily harsh on binary compatibility between versions of
things.
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> *everywhere* (i.e. never) we have to support the configuration file... and
> even if we could do dynamic loading everywhere, I wouldn't be using it on
> a performance critical server.
Wait a minute... WHY ?! Why can't you use the dynamic loadable modules on
a performance critical server ? It's the same thing as having apache
linked dynamically against libc... Are you saying that this will slow
things down ?
> We provide reasonable defaults in Configuration. ./Configure from a
> freshly unpacked apache should provide a working program on most systems.
> The exceptions are those that vary greatly from one distribution to
> another (i.e. linux)... and that I've tried to deal with in 1.3.
Try to look at this from a distribution maintainer point of view. We'd
like to be able to ship aoache modules for Red Hat systems to include
postgres support, other cool stuff, without having to rebuild the apache
binary package every time... It is not only cool, buty it will make apache
easy to deploy on a lot of other cases (think about products like miniSQL,
mySQL, Solid server, etc, shipping their version of apache module and all
you have to do is to stick it into a directory and apache will start using
it..)
> have the issue of translating all of the apache architecture names to the
> equivalent autoconf names and then debugging the entire mess. Not a small
> job.
Any volunteers ? :-) I am one.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
[not sure if you're on new-httpd]
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > If it's an issue of apache 1.2 and -lcrypt on redhat 5.0... that's fixed
> > in 1.3 already (and can't easily be fixed in 1.2 without adding a lot of
> > features). What other issues with 1.3 are there that would require
> > autoconf?
>
> It's not only the -lcrypt issue. What about the ability to configure your
> software without having to edit some configuration file ? Something like:
>
> ./configure --prefix=/usr --httpd-home=/home/httpd \
> --exclude-modules=mod-XX1,mod-XX2
That seems far less handy than editing the Configuration file imho. I
always forget the parameters I use for ./configure... yes I know they're
stowed away in config.status, but I find it hard to hang onto
config.status files for some reason. Apache has far more options than
your usual ./configured program. Until we can do dynamic loading
*everywhere* (i.e. never) we have to support the configuration file... and
even if we could do dynamic loading everywhere, I wouldn't be using it on
a performance critical server.
We provide reasonable defaults in Configuration. ./Configure from a
freshly unpacked apache should provide a working program on most systems.
The exceptions are those that vary greatly from one distribution to
another (i.e. linux)... and that I've tried to deal with in 1.3.
> > various bugs in various versions of various operating systems. These are
> > bugs that we can *not* write a simple sh test for, they're bugs which show
> > up under heavy http loads with non-local clients for example.
>
> I am sure that you are aware that you can handle different architectures
> separately on a case-by-case basis using autoconf as well as standard
> Makefiles...
Yeah like I said, the cygnus guys I talked to mentioned this. Now we only
have the issue of translating all of the apache architecture names to the
equivalent autoconf names and then debugging the entire mess. Not a small
job.
Dean
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Marc Slemko wrote:
> It generates the log, but that isn't automaticaly and directly applied to
> the next time you run it.
yes, it is. You have a .cache file too.
> It just means I'm lazy and don't like typing anything more than
> "./Configure ; make" to preserve any and all options that I used before.
> I can do that now.
Let's make ./Configure a call to ./configure with all the parameters
commented out. Somebody will edit that script and will have the same
result every time. Does that sounds like a compromise ?
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> It generates the log, but that isn't automaticaly and directly applied to
> the next time you run it.
But an autoconf configure also generates a config.status file. For
example, the PHP config.status on my machine has the following comment at
the top:
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host asf:
#
# ./configure --with-mysql --with-apache=/export/home/rasmus/apache-1.3
--with-config-file-path=/u/www --disable-debug --enable-url
-includes --enable-bcmath
#
# Compiler output produced by configure, useful for debugging
# configure, is in ./config.log if it exists.
I believe this is exactly what you are looking for, and autoconf has been
doing this for ages. I simply do a ./config.status whenever I want to
rebuild PHP with the same flags as the last time I ran ./configure.
-Rasmus
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Marc Slemko wrote:
>
> > I hate software like that because it is a royal pain to keep track of
> > exactly how something is complied.
>
> Autoconf will create for you a configure.log file
> whcih will give you exactly that information. Which resembles remarkably
> well with the current way of keeping track how things were compiled (which
> is basically looking into the Configuration _and_ httpd.h files)
It generates the log, but that isn't automaticaly and directly applied to
the next time you run it.
>
> > If I can't go back and do the same
> > thing I did before and get the same result, it is useless.
>
> I am not sure what you mean by that.
It just means I'm lazy and don't like typing anything more than
"./Configure ; make" to preserve any and all options that I used before.
I can do that now.
>
> > A http_paths.h file or something that you could append any paths you want
> > to be non-default would be useful (ie. distributed empty) and would make
> > life easier in that respect, but it doesn't do everything.
>
> You have to know that sometimes maintaining packages with patches is a
> royal pain when the source changes and you have to port a
> distribution-specific patch to the new code base. Yes, I am being selfish,
> but somtimes is just cool to have a script or something with the command
> line that will build apache for you without having to fiddle with
> paches...
cat <<EOF > http_paths.h # no this doesn't work, but it could...
#define HTTPD_ROOT "/foobar"
#define DOCUMENT_LOCATION "/dev/cooltree"
EOF
No, that doesn't solve the modules thing. If you only want to add
modules, it would be possible to have something similar happen with
something that is added to the Configuration file.
>
> > Oh yea, while are are at it... _WHY_ are there so many reports of the
> > RedHat RPM of Apache 1.2.x not giving text/html to .htm files? The base
> > version should...
>
> Somehow a wrong /etc/mime.types file gets installed on that systems, and
> .htm is not defined as being text/html type in that file. We are tracking
> this thig down...
>
> Best wishes,
>
> Cristian
> --
> ----------------------------------------------------------------------
> Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> UNIX is user friendly. It's just selective about who its friends are.
>
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Marc Slemko wrote:
> I hate software like that because it is a royal pain to keep track of
> exactly how something is complied.
Autoconf will create for you a configure.log file
whcih will give you exactly that information. Which resembles remarkably
well with the current way of keeping track how things were compiled (which
is basically looking into the Configuration _and_ httpd.h files)
> If I can't go back and do the same
> thing I did before and get the same result, it is useless.
I am not sure what you mean by that.
> A http_paths.h file or something that you could append any paths you want
> to be non-default would be useful (ie. distributed empty) and would make
> life easier in that respect, but it doesn't do everything.
You have to know that sometimes maintaining packages with patches is a
royal pain when the source changes and you have to port a
distribution-specific patch to the new code base. Yes, I am being selfish,
but somtimes is just cool to have a script or something with the command
line that will build apache for you without having to fiddle with
paches...
> Oh yea, while are are at it... _WHY_ are there so many reports of the
> RedHat RPM of Apache 1.2.x not giving text/html to .htm files? The base
> version should...
Somehow a wrong /etc/mime.types file gets installed on that systems, and
.htm is not defined as being text/html type in that file. We are tracking
this thig down...
Best wishes,
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 2 Feb 1998, Cristian Gafton wrote:
> On Mon, 2 Feb 1998, Dean Gaudet wrote:
>
> > If it's an issue of apache 1.2 and -lcrypt on redhat 5.0... that's fixed
> > in 1.3 already (and can't easily be fixed in 1.2 without adding a lot of
> > features). What other issues with 1.3 are there that would require
> > autoconf?
>
> It's not only the -lcrypt issue. What about the ability to configure your
> software without having to edit some configuration file ? Something like:
>
> ./configure --prefix=/usr --httpd-home=/home/httpd \
> --exclude-modules=mod-XX1,mod-XX2
>
> Wouldn't that be handy ? Instead of browsing through a config file and
> setting yourself compiler flags, library paths - you could have everything
> done for you by autoconf.
I hate software like that because it is a royal pain to keep track of
exactly how something is complied. If I can't go back and do the same
thing I did before and get the same result, it is useless. Yes, autoconf
does save that stuff and it is possible I just find it ugly...
A http_paths.h file or something that you could append any paths you want
to be non-default would be useful (ie. distributed empty) and would make
life easier in that respect, but it doesn't do everything.
Oh yea, while are are at it... _WHY_ are there so many reports of the
RedHat RPM of Apache 1.2.x not giving text/html to .htm files? The base
version should...
Re: apache/linux modules
Posted by Cristian Gafton <ga...@redhat.com>.
On Mon, 2 Feb 1998, Dean Gaudet wrote:
> If it's an issue of apache 1.2 and -lcrypt on redhat 5.0... that's fixed
> in 1.3 already (and can't easily be fixed in 1.2 without adding a lot of
> features). What other issues with 1.3 are there that would require
> autoconf?
It's not only the -lcrypt issue. What about the ability to configure your
software without having to edit some configuration file ? Something like:
./configure --prefix=/usr --httpd-home=/home/httpd \
--exclude-modules=mod-XX1,mod-XX2
Wouldn't that be handy ? Instead of browsing through a config file and
setting yourself compiler flags, library paths - you could have everything
done for you by autoconf.
> various bugs in various versions of various operating systems. These are
> bugs that we can *not* write a simple sh test for, they're bugs which show
> up under heavy http loads with non-local clients for example.
I am sure that you are aware that you can handle different architectures
separately on a case-by-case basis using autoconf as well as standard
Makefiles...
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton@redhat.com -- Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.
Re: apache/linux modules
Posted by Dean Gaudet <dg...@arctic.org>.
> At 02:23 PM 2/2/98 -0500, Cristian Gafton wrote:
> >Also, are you aware of any work in progress to make apache 1.3 use the GNU
> >autoconf program (lower priority, but still doable and cool)
If it's an issue of apache 1.2 and -lcrypt on redhat 5.0... that's fixed
in 1.3 already (and can't easily be fixed in 1.2 without adding a lot of
features). What other issues with 1.3 are there that would require
autoconf?
As Brian mentioned we've had a lot of discussions about this... and ages
ago it did not make sense to use autoconf. But I've since talked with a
few of the cygnus folks and their opinion (albeit biased of course) is
that recent autoconf addresses all of our old concerns. In particular, we
support platforms which don't have sh (or are otherwise unable to
successfully run configure); and our configuration files know about
various bugs in various versions of various operating systems. These are
bugs that we can *not* write a simple sh test for, they're bugs which show
up under heavy http loads with non-local clients for example.
Personally I'd prefer autoconf though.
Dean