Brian,
On Wed, Apr 18, 2007 at 09:24:32AM -0700, Brian Aker wrote:
> Hi!
>
> First off let me add a trick here that we have done in a couple of
> engines. If you need access to more of the MySQL guts you can declare
> this:
> #define MYSQL_SERVER 1
I am somewhat reluctant to do that. Wouldn't this defeat the purpose of
pluggable storage engines: having a well-defined, simple interface between
MySQL and its storage engines, and having a stable plugin ABI for the
lifetime of MySQL 5.1? Also, this dependence on the internal interfaces
of MySQL could cause trouble if MySQL is to support pluggable storage engines
on Windows.
> Before your includes. This is probably not the smartest thing in the
> world, since it will leave you in need of more binary compatibility.
Right. For instance, revising THD by removing or adding a member variable
or a virtual function would likely break binary compatibility.
InnoDB only needs a handful of accessor functions. I can supply an updated
patch that declares these accessors in <mysql/plugin.h> if you have
difficulties merging the patches I sent earlier.
I have a question regarding a modification to
storage/innobase/handler/ha_innodb.cc in
bk://mysql.bkbits.net/mysql-5.1-wl2936:
Why was the handlerton* parameter removed from thd_to_trx()?
Is hander::ht being scheduled for removal? Is it perhaps a little
more efficient to dereference a statically allocated pointer
(innobase_hton_ptr)? Is the storage engine interface based on
class handler being scheluded for removal? I see that much of the
plugin interface is based on function pointers in structs. (That's
actually a good thing, because it allows plugins to be implemented in
any language with C-compatible bindings.)
If the handlerton* parameter of thd_to_trx() was removed on purpose,
I think that the parameter should also be removed from check_trx_exists().
> I believe both PBXT and the AWS engine are now doing this trick. Now,
> you will want to update the ac_mysql.m4 that you are using to the
> latest version I have in the skeleton engine.
>
> You can see the guts of the latest one here:
> http://hg.tangent.org/skeleton-mysql-engine?
> f=7d62ca562f56;file=config/ac_mysql.m4
> And just to put a plug in for the skeleton engine, I am pretty
> liberal about allowing commit access to it, so anyone who contributes
> a couple of good patches can get access to update it directly. Its a
> resource for learning/a starting place for people who need to hook up
> an engine.
I guess this is needed for building plugins outside of the MySQL tree,
right? We are currently replacing the storage/innobase subdirectory
with our own tree. I have edited plug.in and Makefile.am in our own
copy. Instead of storage/innobase/*/Makefile.am, we will use a single
Makefile.am for building all of InnoDB.
Have you found a solution for this warning:
storage/archive/Makefile.am:47: compiling `azio.c' with per-target flags
requires `AM_PROG_CC_C_O' in `configure.in'
We get a similar warning for one of the InnoDB C files
(btr/btr0btr.c, I guess it's the first one listed).
> Cheers,
> -Brian
Regards,
Marko
>
>
> On Apr 18, 2007, at 5:47 AM, Marko Mäkelä wrote:
>
> >On Tue, Apr 17, 2007 at 01:59:43PM -0700, Brian Aker wrote:
> >>Hi!
> >>
> >>Yes, we have been slow about getting the final patch out for loadable
> >>engines in 5.1. If you want to see what it looks like we have made
> >>the tree public:
> >>http://mysql.bkbits.net:8080/mysql-5.1-wl2936/
> >
> >InnoDB is still not loadable, because some of the things it requires
> >are not declared in <mysql/plugin.h> or any of the MySQL header files
> >that are included by storage/innobase/handler/ha_innodb.cc when the
> >preprocessor symbol MYSQL_DYNAMIC_PLUGIN is defined. I'm missing
> >accessors for these members of THD:
> >
> >charset()
> >in_sub_stmt
> >killed
> >memdup()
> >query
> >transaction.xid_state.xid
> >
> >Additionally, these functions or variables are not accessible to
> >plugins:
> >
> >filename_to_tablename
> >get_quote_char_for_identifier
> >global_system_variables
> >lower_case_table_names
> >make_lex_string
> >mysql_bin_log
> >mysql_data_home
> >mysqld_embedded
> >mysql_real_data_home
> >mysql_tmpdir
> >opt_large_page_size
> >query_cache
> >reg_ext
> >specialflag
> >strconvert
> >
> >Will you be merging the patches I sent earlier, or should I prepare
> >new
> >patches?
> >
> >Best regards,
> >
> > Marko Mäkelä
> > Innobase Oy/Oracle Corp.
> >
> >--
> >MySQL Internals Mailing List
> >For list archives: http://lists.mysql.com/internals
> >To unsubscribe: http://lists.mysql.com/internals?
> >unsub=brian@stripped
>
> --
> Brian Aker, Director of Technology
> MySQL AB, www.mysql.com
> Seattle, WA. USA
>
>
>
>
